TVheadend TVHeadend - kein Import von externer M3U im automatischen IPTV-Netzwerk

[absoluteNo1]

Hallo und Guten Tag!

Ich betreibe innerhalb meines Heimnetzes mehrere Kleinrechner (Odroid N2 mit CoreELEC 20.5 und RasPi 4B mit Ubuntu 22.04.5 LTS) mit TVHeadend. Auf beiden laufen

Sie müssen registriert sein, um Links zu sehen.

in der Version linuxserver/tvheadend:arm64v8-653bd040-ls252 (TVH-Version: HTS Tvheadend 4.3-2375~g653bd0400). Das lief bis vor kurzem auch wie geschmiert. Nun habe ich allerdings festgestellt, daß die bereits vorhandenen automatischen IPTV-Netzwerke mit externen Quellen, z.B.

Sie müssen registriert sein, um Links zu sehen.

(Github) oder mein eigene Playlist auf meinem eigenen Webserver (https://....dedyn.io/.../playlists/playlist.m3u), bei Änderungen nicht mehr aktualisiert werden. Bei zum Testen neu erstellten automatischen IPTV-Netzwerken werden keine (NULL) Muxe angezeigt. Bei bereits vorhandenen automatischen IPTV-Netzwerke mit internen Quellen, also z.B. file:///.../plalist.m3u oder

Sie müssen registriert sein, um Links zu sehen.

, funktioniert das weiterhin erwartungsgemäß gut.

Mysteriös ist die Tatsache, daß das EPG aus externen Quellen, also vom gleichen o.g. Webserver (https://....dedyn.io/.../xmltv/epg.xml), weiterhin mehrmals täglich aktualisiert wird. Aus der Konsole der Container kann ich die externen Webserver (Github und meinen eigenen (....dedyn.io)) auch anpingen und die Playlist herunterladen. Die Namensauflösung funktioniert also. Eine Fehlkonfiguration schließe ich also aus. Sowohl auf dem Odroid, dem RasPi als auch im Netz.

Abgesehen davon habe ich bereits den Container von linuxserver/tvheadend:arm64v8-ec56067f-ls179 auf linuxserver/tvheadend:arm64v8-653bd040-ls252 aktualisiert und einen jungfräulichen Container mit eigenen auch jungfräulichen Volumes angelegt - ohne Erfolg, also mit dem gleichen schleierhaftem Verhalten.

Kann das jemand erklären und hat möglicherweise auch einen Lösungsansatz parat?

Ron

 

[salidos]

Shell im Container öffnen, darin:
curl -v

Sie müssen registriert sein, um Links zu sehen.

Kommen Fehler?
Container mit Network host gestartet?
Was sagt das tvh Log?

 

[absoluteNo1]

Shell im Container öffnen, darin:

Hallo!
Du meinst docker exec -it ....
Ich hatte ja bereits geschrieben, daß ich "Aus der Konsole der Container ..." (Konsole = Shell) die externen Server anpingen und die Playlist herunterladen kann. Ich benutzte zwar wget, statt curl. Macht aber keinen Unterschied (keine Fehler):

Spoiler

root@tvh:/config/playlists#curl -v https://raw.githubusercontent.com/jnk22/kodinerds-iptv/refs/heads/master/iptv/pipe/pipe.m3u
... die Playlist ...
* Connection #0 to host raw.githubusercontent.com left intact
root@tvh:curl -o kn_pipe.m3u https://raw.githubusercontent.com/jnk22/kodinerds-iptv/refs/heads/master/iptv/pipe/pipe.m3u
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  314k  100  314k    0     0  2409k      0 --:--:-- --:--:-- --:--:-- 2435k
root@tvh:/config/playlists#wget https://raw.githubusercontent.com/jnk22/kodinerds-iptv/refs/heads/master/iptv/pipe/pipe.m3uConnecting to raw.githubusercontent.com (185.199.108.133:443)
saving to 'pipe.m3u'
pipe.m3u             100% |*********************************************************************************|  314k  0:00:00 ETA
'pipe.m3u' saved

Mein Container lief und läuft aus Gründen im Bridge-Modus (zwei TVH-Container, weil ich während ich versuche, das Problem auf dem einen zu ergründen, über den anderen auch noch fernsehen möchte.), was ja auch der Normalfall ist. Das funktionierte ja bis vor kurzem. Das Port-Mapping ist ja auch für die eingehenden Verbindungen (9981 für´s Web-UI und 9982 für die TVH-Clients) relevant. Web-UI und Client-Zugriff auf den TVH-Server funktionieren ja tadellos.

Das bringt mich auf den Gedanken, ob nicht möglicherweise der https-Zugriff (Port 443) auf die externen Playlist-Quellen gestört ist. Denn das ist das, was die externen Playlist-Quellen zu der Playlist-Quelle in meinem heimischen Netzwerk unterscheidet. Innerhalb meines Netzwerkes greife ich ja über Port 80 (also http:// ...) auf meine Playlist zu. Leider kenne ich keine externe Playlist-Quelle, die über Port 80 erreicbar wäre. Die Zertfikate der externen Webserver (github und mein eigenes) sind im übrigen gültig.

Dieses Verhalten hat sich ohne mein Zutun eingestellt. Eher zufällig als ich eine neue Playlist einbinden wollte habe ich das Problem entdeckt. Bis dahin habe ich lediglich sporadisch geguckt, ob irgendwelche Muxe dazu gekommen sind oder sich welche geändert haben, um diese dann zu mappen.

Das normale tvheadend log gibt mir leider nur dann Auskunft, wenn der (Re-)Fetch der Playlist funktioniert. Das Debugging werde ich jetzt im Anschluß aktivieren, dann testweise ein neues automatisches Netzwerk anlegen, um dann mal zu sehen, was dann in meinem debug.log steht. Allerdings brauche ich dafür eventuell noch Support, denn auf der Debugging-Registerkarte habe ich bisher nie was konfigurieren müssen.