Skip to content

[Feature] Local health check button, channel status tagging, and status-based hiding #410

Description

@FSSocrates

Is your feature request related to a problem? Please describe.

When managing large M3U or Xtream playlists, users frequently encounter channels that are offline, buffering slowly, or restricted by unsupported protocols/auth errors. Currently, the only way to test a stream's health is to open each channel individually, which is tedious and slow when auditing an entire subscription.

User scenario

IPTV subscription users who regularly manage large channel lists. They need to verify stream availability and speed locally before playback—especially after loading new playlists or when facing playback failures—so they can quickly filter out broken or slow streams and maintain a clean layout.

Describe the solution you'd like

Add a local 🎯 Check health button to each subscription/playlist. Tapping it initiates a background check across the channels in that subscription and displays a status badge beside each channel:

  • 🔴 Live: High speed / low latency broadcasting response.
  • ⭕ Record: Pre-recorded media rather than being transmitted in real time.
  • ⏳ Slow: High latency, low throughput, or delayed initial response.
  • 🛡️ Reachable: Host responds (HTTP 200 OK), but media throughput is unverified.
  • ⏱️ Timeout: Request timed out before receiving headers/data.
  • ⛔ Down: HTTP 404/500 errors, broken link, or host down.
  • ⚠️ Error: SSL/TLS error, user-agent/auth failure, or unsupported protocol.

Additionally, provide an option to automatically hide channels assigned specific tags (e.g., hiding all ⛔ Down or ⏱️ Timeout streams).

Describe alternatives you've considered

  • Manually playing each channel one by one to test availability.
  • Using external desktop M3U editing software to prune playlists prior to importing them into M3UAndroid.

Platform scope

  • Smartphone
  • Android TV
  • Both Smartphone and Android TV
  • Not sure

Compatibility impact

  • No known compatibility impact
  • Yes, describe below
  • Not sure

Additional context

  • Tests should run locally using direct HTTP HEAD or GET requests from the user's device for accurate local network results.
  • To avoid rate limits or network saturation, tests should run sequentially or with capped concurrency (e.g., max 3–5 parallel requests).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions