Beiträge von Zabrimus

  • [Patch] iptv: Retune und Obsolete Channels

    Zitat von kls

    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.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Zitat von jojo61

    Den hast du dann vermutlich nicht aktualisiert.

    Na selbstverständlich ist alles aktuell. Bei meinen Sachen achte ich da besonders drauf ;)

    Ist das eine alte Version oder hast du neu gecloned? Falls alt, dann solltest du cef nochmal neu laden

    Code
    rm -Rf subprojects/cef
./setup.sh arm64
meson setup build
cd build
meson compile
meson install

    Falls du arm64 nutzt, ansonsten arm.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Zitat von jojo61

    ../browserclient.h:78:10: error: ‘void BrowserClient::OnRenderProcessTerminated(CefRefPtr<CefBrowser>, CefRequestHandler::TerminationStatus, int, const CefString&)’ marked ‘override’, but does not override 78 | void OnRenderProcessTerminated(CefRefPtr<CefBrowser> browser, TerminationStatus status, int error_code, const CefString& error_string) override;

    Vor 4 Monaten gab es bei CEF genau diese Änderung in der Signatur der Prozedur OnRenderProcessTerminated. Ich denke, du hast da noch eine alte cef-Version liegen.


    Code
    ./clean-package.sh _cef
./build.sh -config CoreELEC-22-no -package _cef
./build.sh ...Deine Parameter...

  • [iptv] m3u Erweiterung

    Auch ein blindes Huhn findet mal ein Korn. Den Code mit Ausgaben gepflastert bis eine Unregelmäßigkeit aufgefallen ist.

    Mehrere Threads, die sich die Variablen gegenseitig überschreiben und damit einen inkonsistenten Zustand erzeugen.

    Jetzt muss ich nur noch überlegen, wie ich die Locks vernünftig setze.

  • [iptv] m3u Erweiterung

    Das ist zum Haare raufen - aber sowas von.

    Der Wechsel von RADIO nach M3U macht Probleme. Umgekehrt funktioniert alles, auch Wechsel innerhalb des Protokolls geht einwandfrei (RADIO -> RADIO, M3U -> M3U und auch M3U -> RADIO). Und der Wechsel von RADIO -> DVB -> M3U funktioniert.

    Das ist auch unabhängig vom Ausgabedevice. Probiert habe ich softhdcuvid, softhddevice und softhdodroid.


    Ich kann das Problem einfach nicht lokalisieren. Es sieht alles gut aus und bisher habe ich keine Änderung gefunden, die irgendwie ein anderes Verhalten erzeugt und mehr Hinweise gibt - egal welche.

  • [iptv] m3u Erweiterung

    To make it easier, i created a release tag v2.6.0. The latest VDR api is 2.6.9. The samples are not yet copied, because they are new.


    Zurück zu den Änderungen:

    - der PidScanner existierte in den Sourcen, wurde aber überhaupt nicht aufgerufen. Die Einstellung P=1 in der channels.conf hatte keine Auswirkungen. Das wurde geändert.

    - Die Bestimmung der Audio-Pids wurde verbessert (nutzt dazu den PidScanner bei der Einstellung P=1)

    - Die M3U Samples (channels.conf) wurden soweit verbessert/geändert, daß keine Obsolete Channels mehr auftauchen.


    Was stört mich noch?

    - Die Radio-Channels werden abgespielt, aber das letzte Bild des TV bleibt stehen. Ich denke darüber nach, ein Bild aus dem Radio-Plugin zu übernehmen oder ein schwarzes Bild anzeigen zu lassen.

    - Es gibt noch einen schweren Fehler beim Wechsel von einem Radio-Channel zu einem M3U-Channel. Mein Ausgabedevice (softhdcuvid) läuft Amok, Puffer laufen über, Bild und Ton sind eine Katastrophe.... Meine Vermutung ist, daß ich die Ausgabedevice-Puffer löschen muss, so wie ich es auch im web-Plugin machen musste. Das probiere ich noch.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Zitat von vdr_rossi

    Bei CE22 klappt es noch nicht, siehe dvb-latest failed to build.txt

    Auf das Update habe ich mich mental vorbereitet und die Probleme konnten gelöst werden. Das betrifft aber nur das Update, das Addon schlägt immer noch fehl. Ich denke da gibt es Probleme mit dem Kernel und Mediabuild. Die passen nicht (mehr) richtig zusammen.

    Ich wüsste gar nicht, wo ich da anfangen sollte.

  • [iptv] m3u Erweiterung

    Zitat von fiveten_59

    In any case I don't understand why and where the plugin call to the libraries

    Many m3u URLs uses https therefore the ssl libraries are needed. I now believe that the SSL libraries have been implicitly linked on my system. e.g. via curl. But more important is, that it works now.

    Code
    ldd /usr/lib/x86_64-linux-gnu/libcurl.so
    libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f1001905000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f1001400000)

  • [iptv] m3u Erweiterung

    Zitat von fiveten_59

    I cant' resolve the problem "undefined symbol: SSL_connect"

    Everything compiles but then start fails? And also a difference between Ubuntu 22.04 and Fedora 40? Sounds strange...


    Hmm. After checking the Makefile the liibs ssl and crypto does not exists,

    Could you please check if everything works, if you change the Makefile (Line 57)

    Code
    LIBS = $(shell curl-config --libs) -lssl -lcrypto

    This is of course an error. I only want to check if there does not exists another problem.

  • [Patch] iptv: Retune und Obsolete Channels

    Zitat von lnj

    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.

  • [Patch] iptv: Retune und Obsolete Channels

    Zitat von Dr. Seltsam

    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.

  • [Patch] iptv: Retune und Obsolete Channels

    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.


    Zitat von kls

    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.


    Zitat von kls

    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.

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