@Stoatwblr root cause confirmed and fix is up at #570.

CECTag::WriteChildren / ReadChildren encoded the children count on the wire as a uint16, so for any tag with more than 65535 children — most notably the EC_OP_SHARED_FILES response, which adds one child tag per shared file — the count silently truncated. amulegui's "Shared Files (N)" label is just wxListCtrl::GetItemCount(), so it ended up showing whatever subset of the truncated response amulegui managed to parse. The downstream "no downloads showing" symptom you noticed had the same root cause: the truncated count desynchronised the rest of the EC packet stream, so subsequent traffic was mis-parsed.

The fix uses a sentinel-extended encoding (0xFFFF followed by uint32 for counts that overflow), gated on a new EC_FLAG_LARGE_TAG_COUNT capability negotiated in the auth handshake, so mixed-version EC stays safe (both sides fall back to the historical wire format with no protocol breaks). Verified end-to-end with a synthetic 70001-file library: matched fix-pair delivers the full set; mixed-version pairs cap cleanly at 65534 with no parse errors.

Both daemon and amulegui need to be on the fix to see the full library. Pre-fix peers on either side behave as they did before (capped at 65535) — no regression.

Uh oh!

Amulegui shared file counter wrong #199

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions