Beiträge von rdorsch

    Kurzes Update: Mit libreelec 12.0 Beta 1 und Kodi 21 funktionieren die Livestreams in ARDundZDF wieder tadellos auf rock64.

    Kurzes Update:

    Mit

    #KODIPROP:inputstream=inputstream.adaptive
    #KODIPROP:inputstream.adaptive.manifest_type=hls
    https://mcdn.daserste.de/daserste/de/master.m3u8

    als .strm file bekomme ich das Problem jetzt doch reproduziert. Kann nicht sagen, warum das heute morgen funktioniert hat.

    Das sieht identisch zu dem aus, was ich im .strm file mache.

    Einzig:

    li.setMimeType('application/vnd.apple.mpegurl')

    setzte ich nicht explizit, aber wenn ich die Zeile auskommentiere, sehe ich keinerlei Verbesserung (aber auch keine Verschlechterung).

    Allerdings startet die Wiedergabe dann frühestens an dem Zeitpunkt, an dem ich den Stream gestartet habe.

    Evtl. hat der Stream selbst ein Problem, auch nach einem Reboot von libreelec kann ich bis zu dem fixen Zeitpunkt zurückscrollen. Es scheint nichts mit dem Zeitpunkt zu tun zu haben, an dem ich den Stream gestartet habe.

    Aber immerhin funktioniert der Stream als .strm file zumindest ganz ordentlich.

    Danke für die ausführliche Antwort.

    Ich wollte mal den Streamlink, den ARDundZDF verwendet in einen strm file kopieren und direkt probieren bzw. damit einen kleinen Testcase für inputstream.adaptive zu bauen.

    Ist

    https://mcdn.daserste.de/daserste/de/master.m3u8

    was als ARDSource verwendet wird?

    Wenn ich den Streamlink in eine .strm Datei kopiere

    rock64:~/fs/videos/Streams/TV # cat test.strm
    #KODIPROP:inputstream=inputstream.adaptive 
    #KODIPROP:inputstream.adaptive.manifest_type=hls 
    https://mcdn.daserste.de/daserste/de/master.m3u8 
    rock64:~/fs/videos/Streams/TV #

    wird mir zwar der 2h Puffer angezeigt, in dem ich auch scrollen kann.

    Allerdings startet die Wiedergabe dann frühestens an dem Zeitpunkt, an dem ich den Stream gestartet habe.

    Fehlt mir da noch ein inputstream.adaptive Property? Kann ich irgendwo sehen, welche properties ARDundZDF für eine Stream setzt?

    Ich habe jetzt mal auf https://github.com/xbmc/inputstream.adaptive nachgelesen. Dort wird empfohlen ein strm file abzuspielen.

    Habe mich erinnert, dass ich noch dash files habe, die ich folgendermaßen runtergeladen habe:

    curl --silent https://raw.githubusercontent.com/jnk22/kodinerds-iptv/master/iptv/dash/dash_tv.m3u | sed s/inputstreamaddon/inputstream/g

    Das überraschende Ergebnis:

    • In den dash streams kann ich vor- und zurücknavigieren, habe keinen einzigen Ausfall beobachtet.
    • Mit dem ARDundZDF Addon ist die Ausfallrate 100%.

    Ich schließe daraus, dass es ein inputstream.adaptive Problem ist.

    Hier ist eine kodi.log, zuerst im dash-file häufig vor- und zurücknavigiert, dann am Ende noch 1x mit dem ARDundZDF Addon und ich habe den Hänger:


    https://paste.libreelec.tv/more-albacore.log

    Werden da vielleicht unterschiedliche Player verwendet?

    Das Log endet mit Ausgaben von inputstream über den beabsichtigten Wechsel zur 60-min-Position (Seek time 3584.1). Es enthält keinen Sync-Error und gibt auch sonst keinen Hinweis auf mögliche Ursachen für Blockaden. Ich kann daher nur meinen Tip im Post #3.383 (Änderungen der Settings für das inputstream-Addon) wiederholen. Siehe auch User-FAQ im Wiki (Videos stuttering problem).
    Du musst dir darüber im Klaren sein, dass der Streambuffer eine erhebliche zusätzliche Last für Raspi und Netzwerk bedeutet.
    /R

    Die Hardware ist ein rock64, Netzwerk Gigabit Ethernet, dann 250 MBit/s Glasfaser :)

    Ich habe den Eindruck, dass da was Fundamentaleres kaputt gegangen ist. Während das Problem vorher nur in seltenen Fällen aufgetreten ist, ist es jetzt 100% reproduzierbar.

    Evtl. habe ich das Problem mit einem LibreELEC Update eingefangen (nur weil mir sonst Nichts einfällt). Auflösung auf 480p reduzieren hat leider auch keinen Effekt.

    Ich weiß nicht, ob das relevant ist, aber im Stream von tvheadend (über dasselbe Netzwerk angebunden) zu springen funktioniert nach wie vor problemlos.

    rdorsch:

    interessant im Log ist der DBusError ('net.connman.Error.Failed -- Network is down') mit einem umfangreichen Diagnostic-Erguss. Er hat wohl aber mit dem Blockierproblem nichts zu tun, denn drei Minuten später geht es mit normalen Logmeldung weiter. Außerdem wird die letzte Startpost-Info aus dem Kodinerds-Forum korrekt abgerufen.


    Der Start des ARD-Livestreams dann fünf Minuten später findet aber noch mit aktiviertem inputstream-Addon statt (ARDundZDF --> SetInputstreamAddon:). Nachfolgend enthält das Log dazu passend die Meldungen von inputstream.adaptive, einschl. der Timeouts (z.B. inputstream.adaptive: Seek time 4784.0 for stream: 1002, OutputPicture - timeout waiting for buffer). Die Blockade überrascht hier also nicht.

    Um beim nächsten Versuch sicher zu gehen, dass inputstream-Addon nicht genutzt wird, kannst du auch im Kodi-Menü Kategorien -> Benutzer-Addons inputstream.adaptive deaktivieren. Es genügt aber auch die Deaktivierung im Addon - das habe ich nochmal überprüft.

    /R

    In der Tat hatte die Deaktivierung des inputstream-Addons nicht funktioniert. Ich hatte mich schon gewundert, warum ich im Streampuffer immernoch navigieren konnte. Leider bekomme ich das Problem nur halbwegs zuverflässig reproduziert, wenn ich im Streampuffer navigiere. Daher muss ich erstmal eine Methode finden, wie ich die Blockade zuverlässig ohne Streampuffernavigation triggere.

    Du hattest vorher vorgeschlagen Settings für das inputstream-Addon zu ändern, hattest Du da an bestimmte gedacht?

    Ich habe gerade das inputstream addon im ARDundZDF addon dekativiert und bekomme es aber trotzdem hin, dass kodi hängt. Hängt heißt hier, dass kodi keine neuen Streams abspielt, Navigation im Menü oder login per ssh sind nach wie vor möglich.

    https://bokomoko.de/~rd/kodi/kodi_stream_stalled_4.log

    Wenn ich mich viel im Streampuffer bewege, erhöht das die Auftrittswahrscheinlichkeit. Bei lokal (bzw. auf NFS-Share) gespeichertem Content, habe ich die Hänger bisher zumindest nicht beobachtet.

    Auch nach dem Einzelupdate von util.py habe ich einen eingefrorenen Stream gesehen, der relevante Teil im [definition='1','2']kodi.log[/definition] sieht aber anders aus:

    Ich hatte hier versucht ganz ans Ende des Puffers zu springen (d.h. zu dem Inhalt, der gerade gesendet wird).

    Der Vollständigkeit halber das kompette [definition='1','0']log[/definition]: https://bokomoko.de/~rd/kodi/kodi_stream_stalled_2.[definition='1','0']log[/definition]

    Ich werde jetzt mal "Stream-Uhrzeit einblenden" abschalten.

    Ich habe immer mal wieder das Problem, dass ein Livestream in ARDundZDF hängen bleibt.

    Im [definition='1','2']kodi.log[/definition] sehe ich dann

    Code
    2024-01-20 11:04:57.698 T:30934    info <general>: CVideoPlayerAudio::Process - stream stalled

    Der Stream läuft erst wieder weiter, wenn ich einen Reboot durchführe (LibreELEC 11.0.5 on rock64 (rockchip 3288))

    Ich sehe vorher auch ein paar Fehler im [definition='1','2']kodi.log[/definition], aber zumindest ich sehe keinen Zusammenhang (sind sie harmlos?).

    Code
    rd@h370:~/tmp.nobackup$ grep 'error <' [definition='1','2'][definition='1','2'][definition='1','2']kodi.log[/definition][/definition][/definition]
    2024-01-20 10:32:07.379 T:1006    error <general>: DBus error: org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files
    2024-01-20 10:34:05.461 T:1006    error <general>: Control 55 in window 10025 has been asked to focus, but it can't
    2024-01-20 10:35:28.020 T:1500    error <general>: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
    2024-01-20 10:36:07.773 T:1500    error <general>: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
    2024-01-20 10:37:03.346 T:1500    error <general>: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
    2024-01-20 10:37:32.545 T:1500    error <general>: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
    2024-01-20 10:40:42.469 T:1500    error <general>: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
    2024-01-20 10:42:52.407 T:1006    error <general>: Control 55 in window 10025 has been asked to focus, but it can't
    rd@h370:~/tmp.nobackup$

    Das komplete [definition='1','2']kodi.log[/definition].

    Ideen und Hinweise jeglicher Art sind willkommen :)

    Update: Das Forum zerschießt meine Links auf [definition='1','2']kodi.log[/definition] :-/ Daher nochmal der explizite Link https://bokomoko.de/~rd/kodi/kodi_stream_stalled.[definition='1','0']log[/definition]

    Bei der Anzeige der Sendungen im Zeitpuffer im Addon handelt es sich um eine Erweiterung der Option "inputstream.adaptive: Stream-Uhrzeit einblenden" für ARD-Livestreams (siehe Wiki). Für die Anzeige ausgewertet werden die im Wiki genanten Tasten. Die ESC-Taste ist dort nicht vorsehen. Leider kann das Addon beim Player-Betrieb keine exaktes Auslesen des Tastaturpuffers gewährleisten. Falls es hier zu Überschneidungen mit ungewollten Funktionen kommt, empfehle ich das Abschalten der Option.

    /R

    Danke für den Link und die Erklärung.

    Ich hatte selbst erst in der Doku gesucht, aber die passende Stelle nicht gefunden. Habe aber auch nicht erwartet, dass im Settings-Modul beschrieben ist, mit welchen Tasten ich die Sendungen im Zeitpuffer anzeigen kann.

    Funktioniert hier aber leider nicht stabil, zumindest scheint es eher zufällig zu sein, was ESC bewirkt. Habe daher wie Du empfohlen hast erstmal wieder abgeschaltet, jetzt funktioniert es wieder stabil.

    Ich habe noch eine Frage zum UI:

    Wenn ich einen TV Livestream schaue, dann erhalte ich "manchmal" bei ESC die Übersicht über gestartete Sendungen im Zeitpuffer, manchmal komme ich auf die vorherige Seite zurück.

    Kann mir jemand sagen, wie ich zwischen beiden Verhalten umschalten kann?

    Danke und Gruß

    ja, ich finde inzwischen auch, dass der Aufwand sich gelohnt hat - also danke zurück.

    /R

    Evtl. lässt sich das Verhalten noch etwa optimieren: Wenn ich das richtig verstehe, lädst Du von tvtoday das Programm für mehrere Tage runter, der Cache wird alle 12h aktualisiert. Wenn der Cache älter als 12h ist, wird er nicht zur Anzeige verwendet. Wahrscheinlich würde das Programm ich Cache aber in 99% der Fälle stimmen. Kannst Du nicht das Programm einfach anzeigen auch wenn der Cache älter als 12h ist. Es spricht ja nichts dagegen den Cache neu zu laden und bei der nächsten Anzeige dann die aktuellen Daten anzuzeigen.

    Es hat etwas gedauert, habe gerade die 4.9.0 getestet, das ist eine riesige Verbesserung! Vielen Dank.

    der Gedanke liegt nahe - vergiss aber nicht den ursprünglichen Zweck des EPG, nämlich Aufnahmen zu ermöglichen. Relevant ist daher das komplette EPG. Zudem wird von der html-Seite wird nur der Textblock mit den EPG-Daten gespeichert.

    Egal, diskutieren ohne Konzept- und Codebezug bringt uns hier nicht weiter. Ich habe aber die Idee, die API-EPG-Daten von ARD und ZDF zusätzlich für die Anzeige der aktuellen Sendung in Überregional und Regional zu nutzen. Dabei handelt es sich um die für die VERPASST-Menüs verwendeten Quellen. Sowie Zeit zur Verfügung steht..

    /R

    Das war mir nicht klar, dass die Intention des EPGs war, Aufnahmen zu ermöglichen, erklärt aber, warum das Design für interaktive Nutzung nicht optimal funktioniert. Trotzdem ist es sehr beeindruckend, was das Plugin alles kann. Vielen Dank dafür.