A channel buffer shows chat and nothing about the stream: no title, category, viewer count or uptime, though /api/v2/channels/{slug} returns all of it and the daemon already calls that endpoint for the chatroom id. Clips and VODs are not reachable either.
Done looks like: the channel header shows title, category and viewers while live, updating on the events that already arrive.
A channel buffer shows chat and nothing about the stream: no title, category, viewer count or uptime, though `/api/v2/channels/{slug}` returns all of it and the daemon already calls that endpoint for the chatroom id. Clips and VODs are not reachable either.
**Done looks like:** the channel header shows title, category and viewers while live, updating on the events that already arrive.
Stream metadata is done; VODs and clips are not, so I am leaving this open — see below.
What landed. The channel endpoint carries the stream's title, category, viewer count and follower count, and this backend has been calling it on every join since the beginning, parsing those fields away and dropping them. They now reach the client as a kickStream event — on join, when a stream starts or ends, and when somebody opens the channel, that last one because a viewer count from an hour ago is worse than none. The header shows a red dot, the title, the category and the viewers while live, and says "offline" outright otherwise, since a quiet channel and an off-air one look identical.
Verified live: winnerdog came through as "sewing :) (silent again)", Art, 38 viewers — and 33 on the next refresh, so the number is genuinely following the stream.
A regression caught in testing, worth recording.followers_count arrives as a number for some channels and as the same number in quotes for others. A strict u64 failed the whole channel parse, so 13 of this account's 29 channels stopped connecting entirely. Both forms are read now, with a test, and an unreadable count can no longer cost a channel.
Still open: VODs and clips. Those are a browsing UI over /api/v2/channels/{slug}/videos and the clips endpoint — a list, a player target, and somewhere to put them — rather than a header field, and none of it is written. Retitling this issue to just that would be reasonable.
Stream metadata is done; VODs and clips are not, so I am leaving this open — see below.
**What landed.** The channel endpoint carries the stream's title, category, viewer count and follower count, and this backend has been calling it on every join since the beginning, parsing those fields away and dropping them. They now reach the client as a `kickStream` event — on join, when a stream starts or ends, and when somebody opens the channel, that last one because a viewer count from an hour ago is worse than none. The header shows a red dot, the title, the category and the viewers while live, and says "offline" outright otherwise, since a quiet channel and an off-air one look identical.
Verified live: `winnerdog` came through as *"sewing :) (silent again)"*, Art, 38 viewers — and 33 on the next refresh, so the number is genuinely following the stream.
**A regression caught in testing, worth recording.** `followers_count` arrives as a number for some channels and as the same number in quotes for others. A strict `u64` failed the *whole* channel parse, so **13 of this account's 29 channels stopped connecting entirely**. Both forms are read now, with a test, and an unreadable count can no longer cost a channel.
**Still open: VODs and clips.** Those are a browsing UI over `/api/v2/channels/{slug}/videos` and the clips endpoint — a list, a player target, and somewhere to put them — rather than a header field, and none of it is written. Retitling this issue to just that would be reasonable.
nobilis 39f8ae3, moho https://git.salastil.com/Salastil/moho/commit/82291f3
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A channel buffer shows chat and nothing about the stream: no title, category, viewer count or uptime, though
/api/v2/channels/{slug}returns all of it and the daemon already calls that endpoint for the chatroom id. Clips and VODs are not reachable either.Done looks like: the channel header shows title, category and viewers while live, updating on the events that already arrive.
Stream metadata is done; VODs and clips are not, so I am leaving this open — see below.
What landed. The channel endpoint carries the stream's title, category, viewer count and follower count, and this backend has been calling it on every join since the beginning, parsing those fields away and dropping them. They now reach the client as a
kickStreamevent — on join, when a stream starts or ends, and when somebody opens the channel, that last one because a viewer count from an hour ago is worse than none. The header shows a red dot, the title, the category and the viewers while live, and says "offline" outright otherwise, since a quiet channel and an off-air one look identical.Verified live:
winnerdogcame through as "sewing :) (silent again)", Art, 38 viewers — and 33 on the next refresh, so the number is genuinely following the stream.A regression caught in testing, worth recording.
followers_countarrives as a number for some channels and as the same number in quotes for others. A strictu64failed the whole channel parse, so 13 of this account's 29 channels stopped connecting entirely. Both forms are read now, with a test, and an unreadable count can no longer cost a channel.Still open: VODs and clips. Those are a browsing UI over
/api/v2/channels/{slug}/videosand the clips endpoint — a list, a player target, and somewhere to put them — rather than a header field, and none of it is written. Retitling this issue to just that would be reasonable.nobilis 39f8ae3, moho https://git.salastil.com/Salastil/moho/commit/82291f3
Vods and clips are beyond the scope of this project