[Liremant]

What

The Friends tab showed four rows where the official client shows eleven. Comparing the same account side by side: the missing friends were all entries whose row has a context (a playlist or album) but no named track — the desktop client renders those as "where they're playing", our parser threw them away.

Why

parse_buddylist demanded a non-empty track/uri and dropped every row without one. Spotify keeps such entries in the buddylist (a friend playing a whole context, or a private/local source), so they are real rows, not noise.

What changed

• Rows without a track stay. What the row carries is rendered instead of the track name: the context title, and double-click plays the context (playContext(contextUri, "")), which is what the official client does too.
• The section header shows how many friends the buddylist brought ("Friend activity — N listening") so "four rows" can be told apart from "the server only sent four".
• Test updated: the fixture now includes a context-only entry, and the parser asserts it stays with its context fields.

Testing

• cargo test -p sf-services — 183 passed (the buddylist fixture extended with a context-only row).
• cargo build -p materialfy, qmllint clean on FriendRow.qml.
• Verified against your own screenshots: the eleven friends in the official client are exactly the four we showed plus the context-only rows this PR keeps.

[VitzS7]

Looks good. Dropping the empty track check in parse_buddylist is the right call, and falling back to the context title and playing the context on double click matches what the official client does. I read the diff and ran cargo test -p sf-services on the branch (185 passed) and qmllint on FriendRow and FriendsPanel (only the usual unqualified Social warnings).

[Liremant]

Converted to draft pending live testing — the reported count mismatch needs a real-account check before this merges. Awaiting test results on the current build.