[RELEASE] Kodi-Addon-ARDundZDF

  • Du nutzt offensichtlich das Setting Vorausladen, was wohl bei vielen abgeschaltet ist.

    "Inhaltstext zu Video im Voraus laden - kann sehr lange dauern!" meinst du, oder?

    Ich hatte kurz Panik, dass ich das wirklich noch eingeschaltet hatte, da ich mich an RE: [RELEASE] Kodi-Addon-ARDundZDF erinnern konnte. Hier hatte ich es zum testen aktiviert.

    Option ist aber aktuell deaktiviert gewesen! Das hätte mir auch alles zu lange gedauert.

    Demnach ist es genau so, wie in deinen Screenshots dargestellt.

    Ich müsste jetzt also erst "Inhaltstext zu Video im Voraus laden" aktivieren, um über das ZDF an die Gästeliste, statt nur an den kurzen Inhaltstext zu kommen, oder?

    Die Kollegen bei https://mediathekviewweb.de/#query=markus%20lanz (siehe unter "˅" ) werten das dann vermutlich anders aus?

    Auf jeden Fall schon mal ganz herzlichen Dank fürs nachsehen und analysieren.

  • Ich müsste jetzt also erst "Inhaltstext zu Video im Voraus laden" aktivieren, um über das ZDF an die Gästeliste, statt nur an den kurzen Inhaltstext zu kommen, oder?

    in der Tat.

    Die Kollegen bei https://mediathekviewweb.de/#query=markus%20lanz (siehe unter "˅" ) werten das dann vermutlich anders aus?

    Davon gehe ich aus. Ich habe mal die Crawlerseite des Mediathekview-Servers überflogen. In der Klasse ZdfConstants sind als Basis-Quellen http://www.zdf.de und api.zdf.de definiert. Mein Addon verwendet das api zdf-cdn und wertet beim Vorausladen die Webseite aus.

    Auf jeden Fall schon mal ganz herzlichen Dank fürs nachsehen und analysieren.

    Keine Ursache - das war auch für mich interessant.
    /R

  • joschi77:
    noch eine Ergänzung: du kannst auch die MediathekViewWeb-Suche verwenden (ohne das Vorausladen-Setting), um an die MediathekView-Texte zu kommen. Edit: das Ergebnis lässt sich seit V4.9.8 in Merkliste/Favoriten übernehmen.

    Edit: und noch eine Ergänzung. Die Zeitdauer für das Vorausladen relativert sich bei der Verwendung als Favorit oder in der Merkliste. Die vorausgeladenen Inhaltstexte werden gecached, so dass lediglich neu hinzukommende Sendungen ausgewertet werden müssen.
    /R

  • Ich habe seit ein paar Wochen das Problem, dass wenn ich im Streambuffer "in die Vergangenheit" scrolle, der Stream hängt.

    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

  • 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.

  • Die Hardware ist ein rock64

    pardon, ich hatte wg. LibreElec einen Raspi unterstellt.

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

    dann lohnt sich ein Versuch mit einem anderem Player, vorzugsweise VLC (unterstützt die 2-/3-Stunden-Zeitpuffer bei ARD/ZDF).
    Der Austausch gegen den Kodi-Player ist im Kodi-Wiki, External_players, beschrieben. Ablauf:
    1. die Datei /usr/share/kodi/system/playercorefactory.xml sichern, dann in Editor laden (nano)
    2. den kompletten Abschnitt <playercorefactory> .. </playercorefactory> ersetzen durch:
    <playercorefactory>
      <players>
        <player name="VLC" type="ExternalPlayer" audio="false" video="true">
          <filename>/usr/bin/vlc</filename>
          <args>--fullscreen "{1}"</args>
          <hidexbmc>false</hidexbmc>
        </player>
      </players>
      <rules action="prepend">
        <rule video="true" player="VLC"/>
      </rules>
    </playercorefactory>

    3. speichern, Kodi neu starten und Livestream testen.
    /R

  • @dorsch: vergiss bitte den Vorschlag "VLC als externer Player" - offenbar lässt sich auf LibreElec kein ext. Player installieren..
    /R

  • 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?

  • In den dash streams kann ich vor- und zurücknavigieren, habe keinen einzigen Ausfall beobachtet.

    wir hatten hier vor zwei Wochen ebenfalls positive User-Hinweise zu Dash-Streams - siehe den Post vom  11.02.2024.
    In meinem Addon verwende ich vorwiegend die Stream-Quellen direkt aus den Mediatheken - Dash-Stream sind im Konzept nicht vorgesehen.
    Theoretisch kannst du in der livesenderTV.xml (../.kodi/addons/plugin.video.ardundzdf/resources/livesenderTV.xml) die Streamlinks bei den gewünschten Sendern eintragen. Das sollte funktionieren, habe es aber nicht getestet. Problem: spätestens beim nächsten Update wird die Datei livesenderTV.xml wieder überschrieben.
    /R

  • 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?

  • 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.

  • Kann ich irgendwo sehen, welche properties ARDundZDF für eine Stream setzt?

    schau mal in die Funktion PlayVideo() im Modul util.py. Ab Zeile 3527 liegt der Block für inputstream.adaptive. Für inputstream.ffmpegdirect habe ich nach früheren Tests die passenden Direktiven im Code belassen (auskommentiert). Für Dash-Links fehlen noch setProperty-Direktiven - ergänze ich noch für eigene Tests (frühestens heute abend).
    https://mcdn.daserste.de/daserste/de/master.m3u8 ist tatsächlich der z.Z. verwendete Live-Link.
    Zur Erinnerung: alle im Addon verwendeten Live-Links werden im Log (Debug-Log aktivieren) ausgegeben, wenn in Infos+Tools der Refresh für die Livestream-Quellen angestoßen wird.
    /R

  • rdorsch:
    ich fasse mal die bisherigen Ergebnisse und die Folgen für das Addon kurz zusammen:
    - Dash-Streams eignen sich bei einigen HW-/SW-Konfigurationen besser für den Kodi-Player (von möglichen Einschränkungen für die max. Auflösung abgesehen)
    - das Addon ARDundZDF unterstützt zwar Dash-Streams (mit neuem Einzelupdate util.py), aber verwendet solche nicht für seinen Livestream-Cache
    - Bei dem Verfahren im Addon wird es vorerst bleiben, solange ich nicht in der Lage bin, die bisherigen Stream-Quellen in den gewohnten Auflösungen als Dash-Streams direkt von den Mediatheken zu beziehen
    - Manuell können Dash-Stream-Links in die Datei livesenderTV.xml eingetragen werden (zwischen den Tags <link> .. </link>, siehe Bild). Für Sicherung und Wiederherstellung bei Addon-Updates muss der Nutzer selbst sorgen
    /R

  • 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.

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

    nun, das ist keine Überraschung. Der enthaltene Link ist ein HLS-und kein Dash-Stream. Die Verwendung einer strm-Datei beeinflusst das Verhalten von Kodi-Player oder inputstream-Addon überhaupt nicht. Sie bietet die Möglichkeit, Kodi direkt einen Link zum Abspielen zu präsentieren, ohne diesen erst aufwändig ermitteln zu müssen. Damit eignet sie sich u.a. zum Platzsparen oder - wie von dir genutzt - für einfache Testszenarien.
    Aus meiner Sicht liegen inzwischen ausreichende Hinweise mein gestriges Fazit vor. Übrigens lässt sich beim Dash-Stream von DasErste der Verzicht auf max. Auflösung sehr schön im Log ablesen: AddOnLog: inputstream.adaptive: Download failed with error 404: http://mcdn.daserste.de/daserste/dash/manifest_1280x720p50_3200k_20240214_b_159569.mp4
    /R

  • Update V4.9.8

    aktuelle Änderungen und Fixes (alle bereits als Einzelupdates verfügbar):

    • Menü TV-Livestreams/Regional: SWR Rheinland-Pfalz aus IPTV-Quelle jnk22 ergänzt
    • Infos+Tools / Einzelupdate: Infotext an letztes Forum-Update angepasst
    • Refresh Addon-Cache für TV-Livestream-Quellen: Ausgabe der TV-Quellen im Debug-Log ergänzt (Format: python-Liste)
    • einige ZDF-Serien wurden nicht gelistet: Programierfehler i.Z.m. Ausschluss-Filter gefixt
    • MVW-Suche (MediathekViewWeb) und Merkliste: Merkliste-Button für Suchergebnisse hinzugefügt, Merkliste angepasst. Siehe Bildfolge MVW*
    • Inhaltstexte vorausladen: einige Sonderfälle beim Zeilenvorschub bei ARD-Inhalten gefixt
    • TV-Livestreams: Berücksichtigung von Dash-Streams (*.mpd) bei Nutzung des inputstream-Addons. Wer Dash-Streams im Addon nutzen möchte, muss diese selbst in die Datei livesenderTV.xml eintragen und selbst für Sicherung und Wiederherstellung bei Updates sorgen. Siehe dazu auch Post #3.477

    /R

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!