[Patch] iptv: Retune und Obsolete Channels

  • Hallo,


    mir sind beim Testen des iptv Plugins 2 Sachen aufgefallen, die sehr störend sind und auch nicht wirklich erforderlich - so zumindest meine Einschätzung.


    1. Retune des Kanals

    Der VDR erkennt Änderungen am Kanal und macht dann ggfs. einen Retune, sprich es wird neu auf den Kanal getuned. Das ist für Kanäle, die durch iptv bereitgestellt werden, eher etwas lästig, weil der Stream, der bereits geladen wird, abgebrochen und ein neuer Download gestartet wird.

    2. Markieren obsoleter Kanäle

    Mir ist aufgefallen, daß iptv Kanäle auf einmal obsolete sind. Die Kanalliste wird für iptv manuell gepflegt und handgeschmeichelt. Daher ist es eher unschön, wenn VDR aus den richtigen Gründen das Falsche macht.


    Im Patch wird die Bedingung !Channel->IsSourceType('I') an 2 Stellen eingefügt, damit beides nicht passiert. Ich denke eigentlich nicht, daß dadurch unerwünschte und überraschende Features aktiviert werden, da der SourceType 'I' speziell nur für iptv existiert.


    prevent_retune_and_obselete_satip.patch.txt

  • Quote

    1. Retune des Kanals

    Warum werden die Kanaldaten dann überhaupt geändert?

    2. Markieren obsoleter Kanäle

    Kanäle werden obsolete, wenn SDT-Daten empfangen werden und sie darin längere Zeit nicht mehr vorkommen.

    Offensichtlich senden also die IPTV-Kanäle SDT, listen aber die betroffenen Kanäle nicht auf. Ist das dann nicht eher ein Fehler in den gesendeten Daten?

  • Ist das dann nicht eher ein Fehler in den gesendeten Daten?

    Das ist sicher denkbar, man könnte versuchen den Stream Anbieter zu kontaktieren. Aber will man wirklich z.B. mit der NASA darüber diskutieren?


    Ausgenommen der Kanal Streams von IPTV Anbietern, z.B. MagentaTV, muss man davon ausgehen das vom Nutzer eingepflegte IPTV Streams sich an nichts halten. Das sind keine TV Kanäle im eigentlichen Sinn.

    HowTo: APT pinning

  • Senden ist vielleicht nicht der richtige Begriff. Es ist im Wesentlichen ein Download und ein muxxen mit FFmpeg und der Übergabe der TS-Pakete an das Device.


    Warum werden die Kanaldaten dann überhaupt geändert?

    Die Hauptänderungen betreffen wohl die Audio PID. Es werden welche entfernt, hinzugefügt. Je nachdem welche Streams beim Start erkannt und "gesendet" werden. Das Problem könnte ich wahrscheinlich entschärfen, wenn ich immer nur einen Audiokanal verwende, aber dann hätte ich das Gefühl etwas zu verlieren.


    Kanäle werden obsolete, wenn SDT-Daten empfangen werden und sie darin längere Zeit nicht mehr vorkommen.

    Offensichtlich senden also die IPTV-Kanäle SDT, listen aber die betroffenen Kanäle nicht auf. Ist das dann nicht eher ein Fehler in den gesendeten Daten?

    Dazu muss ich etwas ausholen. Geladen werden m3u8-Dateien, die entweder im einfachen Fall nur eine URL auf einen TS-Stream haben und im schwierigeren Fall sind die Audio- und Video-Streams getrennt verfügbar und werden durch FFmpeg gemuxxt.


    Ein Aufruf sieht im z.B. so aus:

    Ein Video-Stream (TS) und 3 verschiedene Audio-Streams (AAC). Im Normalfall versuche ich die PIDs gemäß der Konfiguration in der channels.conf zu setzen, damit sich diese relativ fix sind. FFmpeg fügt aber die SDT automatisch hinzu. Jeder Stream ist für sich betrachet völlig isoliert.

    tsanalyze.txt



    Ich hatte anfangs überlegt, ob mit tsduck nicht ein kompletter Transponder erstellt werden kann um die Tabellen vollständig zu haben. Allerdings steht der Konfigurations- und Zeitaufwand in keinem Verhältnis zum Nutzen.

  • wegen des retune aufgrund ständig geänderter Audio-Pids gab es m.E. mal eine Lösung:


    Ich meine mich zu erinnern, dass es da auch noch irgendeinen Trick mit dem Abschnittsfilter, um ständige ungewollte Aktualisierungen der channels.conf und daraus resultierendem retunen zu umgehen? Aktivieren und dann unter 'Deaktivierte Filter' PAT 0x00 auswählen? Oder ist das mit der Lösung von HelmutB aus obigem Link nicht mehr nötig? Ich kriege es nicht mehr zusammen...

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • wegen des retune aufgrund ständig geänderter Audio-Pids gab es m.E. mal eine Lösung:

    Die Frequenzen gehen in den Beispieldateien bis 700. Allerdings sollten die Beispiele in den Samples ziemlich eindeutig sein bei Frequenz/SID/TID.


    Aber jetzt wo Magenta-TV erwähnt wurde, die hoffentlich einen echten Stream liefern, weiß ich nicht, welche Auswirkungen der Patch da hat.

  • I have been using the source-transponder-nid-tid combination in my patch for a long time, because in the case of IPTV, the truly unique part of the channel is the "parameters" in transponder, not the frequency. And in the case of incorrect tables on satellites this also helps. There's more in the patch, take a look, maybe something will be useful.

    vdr-dvbchan-patch/vdr-dvbchan.patch at master · ua0lnj/vdr-dvbchan-patch
    Contribute to ua0lnj/vdr-dvbchan-patch development by creating an account on GitHub.
    github.com

  • I have been using the source-transponder-nid-tid combination in my patch for a long time, because in the case of IPTV, the truly unique part of the channel is the "parameters" in transponder, not the frequency. And in the case of incorrect tables on satellites this also helps. There's more in the patch, take a look, maybe something will be useful.

    I don't have a problem with duplicate channels. Only my M3U channels are marked as obsolete because they run into the CHANNELTIMEOBSOLETE timeout. Beside this, the additional check for the transponder within the obsolete check sounds reasonable.


    Your patch implements support for ISDB-T and DTBM including codecs i have never heard of (AVS and DRA). I'm really the wrong person to ask for integration in core VDR.

  • VDR wurde für DVB geschrieben, alles andere ist "drangepappt". Wenn es also hilft, kann ich prevent_retune_and_obselete_satip.patch.txt gerne übernehmen, da das für DVB keinen Unterschied macht.

    Ich habe eine Möglichkeit gefunden, die channels.conf so zu gestalten, daß keine Obsolete Channels mehr entstehen. Zumindest für iptv/m3u und radio findet das Retune maximal nur noch einmal beim ersten Aufruf statt - so zumindest mein bisheriger Eindruck.

    Wenn die Kanäle erstmal "stehen", dann ist das Umschalten auch angenehm schnell.


    Also insgesamt gesehen würde ich lieber auf den Patch verzichten. Zumal ich die Auswirkungen auf "echte" IPTV-Sender wie Magenta TV, Waipu und wie es sie alle gibt, nicht richtig einschätzen kann.


    Ich weiß nicht, wie es die User sehen, die eben die echten Sender nutzen. Ob es da etwas gebracht hat.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!