BiglyBT
BiglyBT copied to clipboard
BiglySoftware
BiglyBT v3.1.0.0 - Empty/greyed out pieces bar at the peers tab
Java 11.0.15 (64 bit) IBM Corporation c:\program files\semeru\jre-11.0.15.10-openj9
SWT v4942r22, win32, zoom=100, dpi=96 Windows 10 v10.0, amd64 (64 bit) B3.1.0.0/4 az2
Since the update to v3.1.0.0 I see sometimes a few peers with empty/greyed out pieces bar with some connected peers that are downloading/uploading. Is this normal behaviour and has it a reason or?
Just out of curiosity, has no influence on usage of the program itself and works fine.
See picture for an example.
Thanks, Nemo
@Nemo-qB IF I'm reading the code right (big "if", so don't take this as definitive), those maps are rendered as images which are then drawn into the table cell. The gray bar would seem to indicate a missing image.
Which could occur, for example, when the thread that generates it hasn't finished rendering it yet, or is in the process of re-rendering it after a data refresh. It could also occur when detailed piece data isn't available from the peer (yet) — like, it seems as though all peers initially appear in that state, though sometimes it's replaced by a rendered map too quickly to notice. (Much easier to spot on the clients that don't end up staying connected and going into piece-transfer "mode".)
If peers stay in that state for very long — and I suppose it's not a good sign that you had long enough to grab a screenshot, here — then that could be a sign that some changes to that column's refresh code are causing problems. I think there have been some recent changes to some of those drawing routines, but @parg would know better (and probably have written them).
I don't think there is anything new in 3.1 that might be causing this. The grey view is painted when the peer is connected but not yet in a fully ready state, as you say it is odd that it is registering as transfering. As @ferdnyc says, if it stays that way for a long time something must be borked. Try resizing the column to see if that fixes it?
Hmm. Could just be a weird coincidence, but I notice that row also happens to be the only Locally-initiated connection out of the bunch. The rest are all Remotely-initiated. Wonder if there's somehow a pattern there?
You're right parg; The peers that have greyed out bars are not yet fully connected. The others are.
I have made another screenshot to make it clear. Even though they are not yet fully connected up and download works as intended.
My only current explanation is that what you are seeing is a "reconnect" attempt after a peer disconnects. In this case we copy some of the state from the old peer to the new one to maintain things (to avoid a peer from deliberately disconnecting and reconnecting to gain an advantage). The 'stats' of the connection are maintained so although the peer is not yet fully connected you may be able to see old information about upload/download etc. Just a theory but I can't see how a "connecting" peer could actually be in a state to transfer data before getting to the "waiting for handshake " or "fully established" point.
I'll add a "*" to the end of the connection state if it is a reconnect and not yet fully established
My only current explanation is that what you are seeing is a "reconnect" attempt after a peer disconnects. In this case we copy some of the state from the old peer to the new one to maintain things (to avoid a peer from deliberately disconnecting and reconnecting to gain an advantage).
Aren't these (seemingly) always outgoing (L) peer connections, though, not incoming (R) ones, though? That's the only part that seems odd to me, that this state would occur when the local client is the one that initiated the connection.
It indeed seems to happen only with some of the outgoing (L) peer connections as far I have seen. Haven't seen it yet with R peers.
It doesn't happen with all ''L'' peers, see picture (Dutch language). The greyed out one says ''connecting'' while the other one is fully connected and shows the pieces bar. Both are up and downloading fine.