The old player.smotrim.ru/iframe/stream/live_id/N embeds are all dead -
Smotrim's site redesign replaced them with a client-side API
(player-api.smotrim.ru/api/v1/channel/{id}) that returns the current
stream URL. Traced the old numeric id -> new channel id -> stream
mapping from the site's own JS bundle:
- Россия 1 (id 2961 -> channel 1): live.smotrim.ru, no signature, should
be durable
- Россия-Культура (id 19201 -> channel 4): same, unsigned
- Москва 24 (id 1661 -> channel 76): stream.smotrim.ru, carries a `sign`
query param
- Вести ФМ (id 52035 -> channel 199): same, signed
- Соловьёв Live (id 63338 -> channel 292): same, signed
The three signed URLs were stable across repeated fetches in testing
(not IP-bound), but could still rotate server-side - if the checker
flags one of these dead again, re-derive it from
player-api.smotrim.ru/api/v1/channel/{id} rather than assuming the
channel itself is gone.
Not fixed (researched, no working replacement found):
- РТР-Планета: removed from Smotrim entirely - VGTRK now describes it
as satellite-only for the diaspora, no web stream exists
- Катунь 24 / Кубань 24: both stations' own sites just embed the same
dead OK.ru video; OK.ru's underlying stream URL is IP-locked and
expires in ~1 hour, unusable as a static list entry
- Саратов 24: dropped its web player entirely, now Telegram-only
Root cause: Bauer Media Audio Ireland (Today FM, 98FM, Newstalk, Spin
1038, Classic Hits) migrated their stream infrastructure from
stream.audioxi.com to live-bauerie.sharp-stream.com (same mount names,
new host), found via their goloudplayer.com player pages. Sunshine
106.8 moved off sharp-stream onto streamtheworld.com (shared player
config with Nova and Classic Hits' own sites).
FM104 and Dublin's Q102 URLs are unchanged - they were re-verified
returning real audio and appear to have been a transient outage, not
a dead link (worth noting in case #1169's raw-audio-stream detection
fix was also masking these two as false negatives previously).
Note: these URL changes were verified for real audio content (bytes +
correct Content-Type) directly with curl, since check_channels.py
in this repo's history does not yet recognize raw audio/video streams
as alive (see #1169) - verify against that fix once merged.
Some radio stations serve the live audio directly at the listed URL
(Content-Type: audio/mpeg, audio/aacp, etc.) rather than an HLS/DASH
manifest that points to one. probe() only checked for #EXTM3U/<MPD in
the response body, so every one of these was misclassified as dead
regardless of whether the station actually worked.
Found while verifying replacement URLs for Irish radio stations: curl
confirmed real audio bytes with correct audio/* Content-Type on all of
them, but check_channels.py reported every single one as dead. Now
checks the response's Content-Type first; a direct audio/video stream
counts as alive without needing playlist syntax. Verified this doesn't
regress playlist detection (existing HLS/DASH channels still classify
correctly).
Found via each station's own official "diretta/streaming" page, following
embedded iframes/JS one level deeper to the real .m3u8. No hosting
infrastructure was brute-forced. Verified 3x each with check_channels.py,
all consistently alive:
- Travel TV, Donna TV, Alma TV, Italia 7, Lazio Tv, Gold Tv: new
5f11919dca3bd.streamlock.net host (old streaming.softwarecreation.it
provider dead)
- Calabria Uno Tv: same host, working path (ngrp: prefix dropped)
- Canale 21 / Canale 21 Extra: new encoders.immergo.tv provider (old
msvdn.net dead)
- Fascino Tv, Motori Tv: new 64b16f23efbee.streamlock.net host
- Ran Friul: azotosolutions.com load-balancer (old streamlock.net host dead)
- Love in Venice: same host, working path (.stream suffix added)
- Mediterranea Tv: new xdevel.com stream (old aswifi.it dead)
Castrovillari Tv and Cittaceleste Tv are still on their original URLs
unchanged - the outage looks to have been transient, both returned
live content again on retest.
Sportitalia SOLOCALCIO: found a candidate at
distribution.sportitalialive.it/sportitalia/sisolocalcio_abr/playlist.m3u8
(hardcoded in the official player page), but it returns 403 from here -
looks like a datacenter/ASN block rather than a bad URL, so left
unchanged rather than swap in something equally unverifiable.
19 other stations were also researched but had no findable working
replacement (parked/dead domain, JS-rendered player with no static URL,
or the official embed itself already dead) - left unchanged.
Found via each station's own official "diretta/streaming" page, following
embedded iframes (several use a shared white-label player at
player.streamshow.it/hosted/*.php) one level deeper to the real .m3u8.
No hosting infrastructure was brute-forced. Verified 3x each with
check_channels.py, all consistently alive:
- TVL (TV Libera Pistoia): new mariatvcdn.it host (old one dead)
- Teatro Tv: teatrotv.iostream.it (old m.iostream.it path dead)
- Tele Belluno: new mariatvcdn.it host + path
- Tele Cupole: azotosolutions.com load-balancer (old newradio.it dead)
- Tele Ischia: new streamlock.net host
- Tele Radio Ercolano: same saiuzwebnetwork.it provider, working path
- Teleiblea: same streamlock.net provider, working host
- Vera Tv: streamshow.it CDN (old shared streamshow.it host dead)
TG Norba 24 was listed twice under two different EPG rows with the same
tgv-id (TGNorba24.it) - one already pointed at a working
live-telenorba.cdn.netrw.it URL, the other (router.xdevel.com) was dead.
Removed the dead duplicate rather than adding a third entry.
29 other Italian local stations were also researched but had no
findable working replacement (site down, JS-injected player with no
static URL, or official embed itself already dead) - left unchanged.
mediapolis.rai.it's relinker service is now Italy-IP-gated: with
forceUserAgent it 302s to a "video not available" placeholder MP4
(the "raw binary" symptom this repo's checker was seeing), without it
Akamai returns a plain 403. RAI's own official pages (raiplay.it) still
embed the same dead relinker pattern, and no working parameter/domain
variant was found - this isn't a broken link, it's a geo-restriction
that happens to also break for the CI runner's non-Italian IP.
Found a third-party CDN mirror (d3k8wzt41aflvx.cloudfront.net) already
re-serving RAI's linear feeds unrestricted, in the same vein as the
existing Rai4K/UniNettuno akamaized.net mirrors already in this list.
Verified each with curl (multi-quality master playlist, real segment
references) and with check_channels.py (3x each): Rai 2/3/Premium/
Storia/Scuola came back consistently alive, Rai 1 flaky (2/3 ok, real
content each time) - consistent with general CDN flakiness elsewhere
in this list, not a sign the URL is wrong.
Dropped the Ⓖ marker on these 6 since the mirror isn't geo-blocked.
Rai 4, Rai 5, Rai Movie, Rai Gulp, Rai YoYo, Rai Sport, and Rai Radio 2
Visual Radio are not on this mirror and were left unchanged (still
pointing at the geo-gated relinker, since that's genuinely the current
official source and may still work for viewers with an Italian IP).
Both use the same lexanetwork.com infrastructure as FehérvárTV (#1163)
and Kapos TV (#1164). Found via each station's own official live page
(estv.hu homepage, komaromtv.hu/online-adas/), which embeds a player
resolving to a working relay URL. Verified 4x each, consistently alive.
Also searched ~45 other Hungarian local TV stations for lexanetwork.com
usage - none of the others use it (mostly WordPress/YouTube embeds, or
the station's own site is dead), so no further additions from this pass.
Was marked [x] (dead relay01/livestream004.sdp on cloudfront63). Found
the current URL the same way as FehérvárTV (#1163): the official site's
"Élő adás" page embeds an iframe at cloudfront63.lexanetwork.com/itplayer/
LIVE016_inc.php, which resolves to a real master playlist (bitrate/
resolution/codec info + segment reference) on a different host/path -
relay01/broadcast004.sdp on cloudfront44. Verified 4x, consistently alive.
Also checked the site's other dead ([x]) lexanetwork.com entries this
same way: AlföldTV's domain now redirects to a news portal with no live
player, Zugló TV's and Bajai TV's sites don't resolve/load at all, and
Lóverseny közvetítés is an event-only feed (found a newer loverseny3.sdp
path via the same method, but it's only live during actual races, so
nothing to verify against right now). None of those looked fixable.
The old URL (freerelay/fehervartv.sdp) answered HTTP 200 with a
technically-valid HLS header but nothing else - no #EXT-X-STREAM-INF,
no segment reference, just two lines. That passes a header-only check
(and did - the current checker reports it "alive") while being
unplayable in any real player, since there's nothing to play.
Found the working URL by fetching the official player embed at
https://www.fehervartv.hu/elo_adas (an iframe pointing at the same
lexanetwork.com host, but a different relay path - relay44_1/HDE046.sdp
- that does return a real master playlist with bitrate/resolution/codec
info and a segment reference). Verified 4x, consistently alive.
Follow-up to #1156. That PR found working cids (01, 08, 12 - the range
was 02-07,10,11 before) for channels previously marked [NO PUBLIC
STREAM], which is valuable, but it also reassigned the cid of every
already-known-working channel (NHK BS, BS日テレ, BS朝日, BS-TBS,
BSテレ東, BSフジ) to its neighbor's old value - a clean cyclic shift
across exactly six channels, which is what a list/list zip misaligned
by one produces, not what channel-by-channel verification produces.
Neither the old nor the new mapping carries any content-level proof
(the streams have no identifying metadata), so there's no way to tell
which is right - only that the shift itself isn't evidence of anything.
This takes only the part that's unambiguous: three cids nobody had
before, given to the three channels that had nothing. bs07 was one of
the "new" ones in #1156, but it's already BS10スターチャンネル's cid,
so WOWOWシネマ gets bs08 instead - the only other free value.
Verified each new cid resists a single flaky read (checked 4x): bs01
and bs12 came back flaky (3/4 ok) but real, bs08 came back alive (4/4).
That's consistent with how naori-test.netgenx.site behaves generally
(see check_channels.py's docstring), not a sign these three are wrong.
Replaces iptv-checker (npm + ffmpeg) with check_channels.py:
- Checks every channel in a list a PR touches, existing and new, not just
the added/changed rows - a PR editing italy.md now surfaces already-dead
channels in italy.md too, not only the one line it changed.
- Uses check_channels.py's dead/blocked/unreachable/flaky states instead
of a binary online/failed, so the summary no longer needs the "some of
these failures are geo-blocks, use your judgment" disclaimer without
telling reviewers which failures those are - blocked channels are now
named as such.
- Summary separates what the PR actually added/changed from what was
already broken in the same file, so a reviewer isn't left guessing
whether a failure is theirs to fix.
- No ffprobe pass here (kept fast for a PR gate) - anything this flags as
dead gets a second opinion from the scheduled Channel check (deep)
workflow before anyone acts on it.
Verified end to end against a simulated PR diff.
The first scheduled run of #1157's workflows failed outright: a server
started a chunked HTTP response and then hung up mid-chunk, which
urllib surfaces as http.client.IncompleteRead - a subclass of
http.client.HTTPException, not of OSError/URLError/ValueError, so
probe()'s except clause let it propagate and took the whole run down
before it wrote anything to --json, including check_channels_fast.yml's
run.jsonl.
Catch http.client.HTTPException alongside the existing exceptions and
treat it as unreachable, same as any other broken connection. Verified
against the exact exception (mocked) and against the live lists.
Builds on the idea in #1145 (a checker that maps failures back to a channel
and list, and tells a geo-blocked channel from a dead one) with a few
additions:
check_channels.py
- Standard library only, same as #1145's version.
- Adds a `disputed` state: an optional --confirm-dead pass gives ffprobe a
second opinion on anything that looks dead over HTTP, before it gets
reported as dead. This is one-directional (can only pull a verdict out
of `dead`, never push one into it) because ffprobe itself is not
reliable enough to trust in the other direction - a known-good DASH
channel needed longer than any sane per-channel budget to open while
testing this, and a header check alone had already been fooled by an
isolated media fragment sitting at a URL that looked like a live channel
(a mistake made and caught while triaging #1149/#1151 - see the
docstring for the details).
- Restructured to share one worker pool across every list in a run
instead of a fresh pool per list, which stopped small lists from paying
the same wall-clock floor as large ones; a full run across all lists
dropped from not finishing in 15 minutes to about 10.
- --json writes one record per channel per run, for building a history.
generate_dashboard.py
- Turns that history into a single self-contained docs/index.html: current
state breakdown, an alive-share trend across every run kept, a per-list
breakdown, and a searchable/filterable table of everything that is not
currently alive.
Two new scheduled workflows
- check_channels_fast.yml: every 6 hours, HTTP checks only.
- check_channels_deep.yml: every 2 days, with --confirm-dead (needs ffmpeg).
Both append to .github/checker-history/history.jsonl (pruned to 90 days),
then build and deploy the dashboard to GitHub Pages.
Corrects a mistake in the previous PR (#1151): the URL answers with
HTTP 200 and binary data, but that payload is a raw MP4 fragment
(ftyp/moov boxes), not an HLS or DASH playlist a player can open.
No working replacement was found, so removing it rather than
mis-marking it as fixed.
Follow-up to #1144.
- ERT World was renamed to ERT Cosmos. Added back under the new name,
pointed at the same ERT CDN host used by the other ERT channels
(verified HTTP 200 with a valid DASH manifest).
- Star Central Greece was returning 404 when #1144 was tested (Aug 26)
but is back up now - verified 3x with a real MP4/DASH payload, not
an error page. Restored with its original link.
Added to the existing Rチャンネル/Rakuten section: NTV News (日テレNEWS),
FNN Prime Online (FNNプライムオンライン), and MBS News (MBSニュース),
via Rakuten's official Amagi CDN (cdn-apne1/cdn-uw2-prod.tsv2.amagi.tv),
same source already used for the existing Tokyo MX channel.
Verified HTTP 200 for all three, not geo-blocked.
KAMI
Kálmán „KAMI” Szalai
ChannelCheckerBot
PlaylistBot
Fransitiu!