Skip to content

feat: Show live media info and failover channel name on Stream Monitor#1088

Closed
Warbs816 wants to merge 2 commits into
m3ue:devfrom
Warbs816:feat/stream-monitor-media-info
Closed

feat: Show live media info and failover channel name on Stream Monitor#1088
Warbs816 wants to merge 2 commits into
m3ue:devfrom
Warbs816:feat/stream-monitor-media-info

Conversation

@Warbs816
Copy link
Copy Markdown
Contributor

@Warbs816 Warbs816 commented May 2, 2026

Summary

Closes #1085. Stream Monitor now shows live media badges and the active failover channel name, matching the Dispatcharr-style readout requested in the issue.

Pairs with the proxy-side PR that publishes the data: m3ue/m3u-proxy#54.

What changed

Failover channel name — when a stream is on a failover URL the title renders as Primary Name → Failover Name, with the failover name in orange to match the existing Failover Active badge styling. The active failover is identified by URL-matching current_url against PlaylistUrlService::getChannelUrl() for each candidate, which means it works correctly under the dynamic resolver (where the proxy's current_failover_index doesn't necessarily line up with the candidate's slot in failoverChannels). Falls back to index lookup for the static-list mode.

Live media badges — the page now shows resolution / fps / codec / audio / container / bitrate / speed when the proxy reports them. Badges are conditional on the proxy returning a non-empty media_info, so plain HTTP-proxy streams just don't show them rather than rendering empty placeholders.

The page only consumes data the proxy already publishes — there's no extra polling or work in the editor.

Test plan

  • Open Stream Monitor while a transcoded stream is active — resolution, codec, fps and bitrate badges populate within a few seconds
  • Plain HTTP proxy stream — no badges (clean, not empty placeholders)
  • Trigger failover — title shows Primary → Failover with the failover name in orange; badges repopulate for the failover stream
  • With dynamic failover resolver enabled and the first candidate skipped, the title resolves to the actually used candidate (not the first one in the list)

Warbs816 added 2 commits May 2, 2026 01:16
…onitor

When a failover channel is active, the Stream Monitor header now renders the
primary channel title with an arrow to the failover channel title (in orange,
matching the existing Failover Active badge) so it's obvious which backup is
being served. Resolution / FPS / video codec / audio codec / audio channels /
container / bitrate / speed badges appear underneath when the proxy reports
live media_info — these only show for transcoded (ffmpeg) streams; plain
HTTP-proxy streams don't render badges.
…the name

Dynamic resolver mode (the default for users with the Failover Resolver setting
enabled) doesn't keep current_failover_index in lockstep with the position in
failoverChannels — the resolver can skip a candidate when its playlist is at
capacity or has been marked invalid by a fail condition, so index 1 might point
to the second or third channel in the list. Match by URL instead — iterate the
failoverChannels and compare each candidate's PlaylistUrlService::getChannelUrl
output to the proxy's current_url. The 1-based index lookup is kept as a
fallback for the legacy static failover_urls path where index does line up.
@Warbs816
Copy link
Copy Markdown
Contributor Author

Warbs816 commented May 2, 2026

@sparkison let me know how to proceed as per comment on #1085!

@Warbs816
Copy link
Copy Markdown
Contributor Author

Warbs816 commented May 2, 2026

Superseded by #1089, which rebases this work onto dev's new badge UI from 0146613 and layers the live proxy media_info on top of the stored probe data instead of replacing it.

@Warbs816 Warbs816 closed this May 2, 2026
@Warbs816 Warbs816 deleted the feat/stream-monitor-media-info branch May 2, 2026 12:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant