v3.11 Minor bug found with Bitfield values and sometimes wrong % - Help and Support

Help and Support
Ask a question, report a problem, request a feature...
<< Back To Forum

v3.11 Minor bug found with Bitfield values and sometimes wrong %

by Guest on 2022/09/22 07:01:05 AM

Hi KH + Devs!

Great work and congrats on v3.11, totally love it ;-)

Perhaps the Dev's won't be interested in this, but every bug report isn't moaning,
take these reports as "appreciation" as it helps makes a much better product!

1) Bitfield values missing from 'Event Log' info (always=0)
2) Peer tab (Download screen) '% Complete' is sometimes random (IE: showing "11% Both Peers Complete" (contradictory) - I think this affects "REMOTE SEED LIMIT=x" counting.

FURTHER INFO:

1) The bitfield integer is being lost somewhere
2) Sometimes is correctly displayed in PEER tab, sometimes displayed with random % in PEER tab.

So MAYBE there is a variable disassociation in the new v3.11 coding?

Here are some logs:

Event Log

[15:39:11]  receiving secure incoming v1 connection
[15:39:11]  logged in
[15:39:11]  sent bitfield
[15:39:12]  remote is partial seed
[15:39:12]  received bitfield, 0 of 1,306 pieces complete
[15:39:12]  remote is complete seed                               <------- COMPLETE SEED REMOTE - So peer must be 100% - But bitfield reports = 0
[15:39:13]  error: Remote disconnected
[15:39:13]  stopping

Again to prove not isolated case...

[16:17:29]  receiving secure incoming v1 connection
[16:17:29]  logged in
[16:17:29]  sent bitfield
[16:17:30]  remote is partial seed
[16:17:30]  received bitfield, 0 of 1,837 pieces complete
[16:17:30]  remote is complete seed                               <------- COMPLETE SEED REMOTE - So peer must be 100% - But bitfield reports = 0
[16:17:32]  error: Remote disconnected
[16:17:32]  stopping

Thank you so much for your very hard work on Tixati. Much appreciated.

by Guest on 2022/09/22 08:17:09 AM

What OS?
I havn't noticed your problems, I run linux.

by Guest on 2022/09/23 10:30:04 AM

I'm running Win10 64 bit

Oh! Firstly, I think you will need to go into > SETTINGS (gear icon) > Event Logging (almost bottom of list) > PEERS (set from LEVEL=2 to LEVEL=3)

If you now go back and check in the TRANSFERS screen

Select a download, then look in the PEERS tab, where you can see IP numbers, double click random lines here (open up a few popup windows) and look for "bitfield"

then it shows you the pieces are always "0 of 1,234"

I've been using "REMOTE SEED LIMIT=3" on my seeds and in Tixati v3.11 - This will switch off uploads if more than 3 others have 100% - since my connection isn't fiber yet.

I am seeing 3x lines of "Both peers complete" ie 100%, 100% and 67% and REMOTE SEED LIMIT is broken due to this bug.
(Broken because of rogue "67%" despite 3 peer messages saying "Both peers complete"

I think this is a bug.

Very happy with Tixati, thank you for coding v3, will be fabulous to see all the upcoming improvements.

by notaLamer on 2022/09/27 03:45:49 AM

Are you sure peers have selected the entire torrent for download? You could also be sitting at 0% and not interested in anything (yet).

by Guest on 2022/09/27 07:49:48 AM

Hi notaLamer

Taken several screenshots because nobody seems to believe me that I've got issues with v3.11

Take a look at my screenshot please,

1) Bitfield is always 0
2) Tixati says "Both Peers Complete" but percent meter is not showing 100% which you get if the peer has FULL pieces (ie 1,234 of 1,234 pieces)

What do you think now???

Bug or ?

https://ibb.co/r4dCf0V

by Guest on 2022/09/30 06:50:00 PM

Is nobody else seeing the issues reported above (wrong % values - in peers tab) ???

To view these messages you need to up the logging detail,
found in >> SETTINGS (gear icon) > Event Logging > PEERS (second down) change to 'LEVEL3'

###################################################################################

OK this is a contradictory log in Tixati:

NO PIECES remote - But Both peers complete ?? WHAT! (this is a bug)

[13:17:02]  created from incoming connection
[13:17:02]  starting
[13:17:02]  receiving incoming v1 connection
[13:17:02]  logged in
[13:17:02]  sent bitfield
[13:17:02]  remote is partial seed
[13:17:02]  remote has no pieces
[13:17:15]  error: Both peers complete         <---- Shouldn't be seeing this when peer has 0 pieces
[13:17:15]  stopping

gives this unexpected message:

0% Both peers complete

###################################################################################

This is a CORRECT message where I can see the remote seed has 100%

[14:12:13]  logged in
[14:12:13]  sent bitfield
[14:12:14]  remote is partial seed
[14:12:14]  remote has all pieces
[14:12:14]  remote is complete seed
[14:12:20]  error: Both peers complete

THIS IS GENUINE (perfect)

100% Both peers complete

###################################################################################

This above confuses and effectively breaks the setting called "REMOTE SEED LIMIT =X "

It seems like REMOTE SEED LIMIT knows the "0% Both peers complete" are not 'countable'
so I guess the Tixati code logic is OK in ignoring it

Really enjoying using Tixati, just giving the devs constructive feedback so all these issues can be fixed

Thank you for all the hard work. It is greatly appreciated.

by notaLamer on 2022/10/01 02:58:59 PM

The fact that it breaks remote seed limit is obviously bad and also exploitable by nefarious trolls (and this is probably unavoidable anyway without requesting a random piece/block).
So to offer you my support: 0% peers should not be considered "complete" for the remote seed limit.

What I wanted to say in my reply, maybe it's the protocol's intentional way to operate. You CAN be a "complete" peer in the sense you don't want any pieces, because you didn't select any pieces for download. You can be legit sitting at 0% not wanting anything and be "complete" in that regard. But if this is a factual explanation of this (I don't know!) then it still shouldn't be breaking remote seed limit. Thanks for the screenshots again.

by KH on 2023/02/12 07:02:24 PM

The last reply is correct ^^^

The protocol allows for 'partial seeds', and nothing prevents a partial seed with no pieces.

So, from 3.16 forward, for a seed to be counted for the remote seed limit, it must have at least as many pieces as the local client does.

by Guest on 2023/02/12 07:04:58 PM

From the newspage for version 3.16:
the Remote Seed Limit option will only consider partial seeds that have at least as many pieces as local

looks like v3.16 has this working right.

by TX007 on 2023/02/13 11:01:44 AM

by Guest on 2023/02/12 07:04:58 PM

From the newspage for version 3.16:
the Remote Seed Limit option will only consider partial seeds that have at least as many pieces as local

looks like v3.16 has this working right.

Other partial seeds might have more pieces than me, but all are missing some pieces that i have. I suggest that Remote Seed Limit option only consider partial seeds that have all the pieces owned by local.

by KH on 2023/02/14 01:26:33 AM

I suggest that Remote Seed Limit option only consider partial seeds that have all the pieces owned by local.

I was going to do exactly this, but there is a bit of a cost to it, so I decided to use the piece count as a compromise, at least for now.

It would have been necessary to keep the remote peer's bitfield cached after it has disconnected. This can add up to a lot of extra RAM usage in some situations. It's going to take a little bit longer to get this right.

Add Reply

<< Back To Forum