Posts by Zabrimus

    Ja, das ist mein Problem. Ich weiß nicht wie ich es hinbekommen soll, vor dem Start des web-plugins, automatisch den cefbrowser zu starten.

    Das wollte ich eigentlich nicht damit ausdrücken. Ich meinte, daß es egal ist, in welcher Reihenfolge die Programme gestartet werden. Die Verbindung zwischen Browser und dem Plugin wird automatisch hergestellt, sobald die Programme gestartet wurden.

    Ich habe gerade erst den VDR gestartet und bekam natürlich die Fehlermeldung, daß der Browser nicht da ist. Sobald ich aber den Browser gestartet hatte, funktionierte alles. Wenn also das Plugin "zu früh" aufgerufen wird, gibt es die Fehlermeldung. Aber ansonsten verbinden sich das Plugin, der Transcoder und der Browser automatisch.

    Du hast als headless gestartet, wie soll das gehen?

    Der Browser selbst läuft in der Tat headless. Die gerenderte Graphik wir abgefangen und als Bitmap an VDR übergeben und dann im OSD dargestellt. X muss deshalb auch nicht vorhanden oder gestartet sein, sondern nur ein paar Libs, damit das funktioniert.


    Die Fehlermeldungungen beim Start des Browsers haben keinen Einfluss auf die Funktion selbst. Ich weiß nicht, wie man diese abstellen kann um weniger Verwirrungen zu erzeugen.

    Jetzt kann ich am vdr-Rechner web starten und der rote Button wird angezeigt. Mit den Roten-Button komme auf die HBBTV-Seite des Senders und kann Filme abspielen.

    Also im Prinzip funktioniert alles und nur das Zusammenspiel der Startscripte sollte optimiert werden.


    Also muss bevor ist web starte das remotetranscode und cefbrowser gestarte sein.

    Nur wie bekomme ich das hin.

    Hmm. Eigentlich sollte die Startreihenfolge egal sein. Der remotetranscode kommt sowieso erst ins Spiel, wenn ein Film abgespielt werden soll. Es reicht aber auch schon - wie z.B. bei der Tagesschau - das der Film in einem kleineren Bereich abgespielt wird.


    Wenn allerdings das Plugin aufgerufen wird, bevor der Browser gestartet und initialisiert wurde, dann gibt es eine entsprechende Fehlermeldung. Dies sollte aber nach dem erfolgreichem Browserstart nicht mehr auftreten.

    Edit:

    Ach Mist. Ich sehe gerade an den Zeitstempel der Logs, daß die Zeitzone nicht stimmt :( Vielleicht kommt daher das Problem.

    Also.... Das unten kann man dann wieder vergessen.


    ------- nicht mehr wichtig -------

    Ich habe versucht eine frische Aufnahme durch markad laufen zu lassen. Allerdings habe ich relativ schnell abgebrochen, weil die Fehlermeldungen ziemlich seltsam sind:

    Ist das normal, daß der Recording Start und der Timer Start fast 2 Stunden auseinander liegen?


    Code
    markad: Mon Sep 30 19:03:59 [15475] ERROR: recording start 117:05 min after timer start, recording incomplete, marks will be wrong

    Die Aufnahme habe ich gerade gesichtet und die ist vollständig. Nur eben mit Werbung und ohne Markierungen.

    Es gibt keine Parameter-Kombi, die für ca. 90% aller Sender/Einträge ein gutes/optimales Ergebnis liefert?

    Sagen wir mal so. Ich bin mit den aktuellen Parametern zufrieden und sehe - für mich - keine Notwendigkeit etwas ändern zu müssen. Mit FFmpeg für Video und vlc für Radio habe ich bisher keine Probleme gehabt. Aber es gibt 2 Meldungen, bei denen eine Änderung notwendig sein könnte:

    1. fps ist nicht 25/50, sondern 30 oder etwas anderes. Das Video hat dann Mikroruckler

    2. Für vlc und Video gab es die Notwendigkeit (siehe #136) die Default Parameter zu ändern, damit es funktioniert.


    Den Vorschlag von MarkusE würde ich gerne erweitern um sowohl eine einfache Einstellung, als auch komplizierte Scripte zu ermöglichen.


    Idee (zur Diskussion):

    1. Eine Ini-Datei mit der Channel Id als Section

    2. Als Key/Value 2 Möglichkeiten:

    a) Der komplette Aufruf für den Kanal, der selbst erstellt werden müsste. Als Platzhalter würden dann die Video- und Audio-URL angegeben werden.
    b) Ein Script, das aufgerufen wird mit dem Eintrag aus der channels.conf + Video-/Audio-URL und Ausgabe wäre der komplette Aufruf. Dazu könnte man ein Script-Skelett erstellen, daß verschiedene Werte schon bestimmt. Vorteil wäre, das man auf Audio-Channels verzichten kann oder den Transcode genauso machen kann, wie man will.


    Sollte die Channel Id nicht in der ini Datei zu finden sein, dann wird der aktuelle Aufruf verwendet und damit wäre das Ganze abwärtskompatibel und man könnte für bestimmte Kanäle (falls erforderlich) eben eine Sonderbehandlung vorsehen.


    Beispiele:

    Code
    [I-1-34-21-21]
    script=/pfad/zum/script/mach_was_tolles.sh
    
    [I-1-17-7-7]
    transcode3=ffmpeg -hide_banner -re -y... -i {V} .. -i {A1} .. -i {A2} ... -i {A3} -codec copy -map 0:v -map 1:a ... usw.
    transcode2=ffmpeg -hide_banner -re -y... -i {V} .. -i {A1} .. -i {A2} ... -codec copy -map 0:v -map 1:a ... usw.
    transcode1=ffmpeg -hide_banner -re -y... -i {V} .. -i {A1} ... -codec copy -map 0:v -map 1:a ... usw.


    Der erste Eintrag verweist auf ein Script und bekommt die Parameter:

    <Eintrag aus der channels.conf> <video-url> <audio-url 1> <audio-url 2> <audio-url 3>

    Der zweite Eintrag ist eine stark verkürzte Version aus #138 und enthält die Platzhalter für die Video-/Audio Urls. Wobei es 3 Versionen gibt (jeweils für die Anzahl der Audio-URL (1,2 oder 3)).


    Das Ganze würde natürlich für vlc ähnlich aussehen.


    Vorteile:

    Es gibt sowohl eine Möglichkeit einer einfachen Konfiguration oder eben die Möglichkeit ein Script anzuwerfen, in dem so alles gemacht werden kann.

    Sollte die ini-Datei nicht vorhanden sein, oder der Eintrag für die channel-id fehlen, würde der Bestandscode greifen. Niemand wird also dazu genötigt eine weitere Konfiguration zu erstellen. Es besteht aber die Möglichkeit auf bestimmte Kanäle flexibler reagieren zu können.


    Nachteile:

    Entwicklungsaufwand entsteht.

    Dokumentationsaufwand entsteht.

    Die Aufrufe von FFmpeg und vlc nehme ich immer wieder unter die Lupe und überlege, welche Möglichkeiten es gibt, diese von außen beeinflussen zu können. Bisher ist mir aber aufgrund der vielen Parameter keine vernünftige Lösung eingefallen, die ein mögliches Script nicht zu unübersichtlich oder nur sehr schlecht wartbar machen.


    Zum Beispiel kann der FFmpeg Aufruf für den Kika Stream zu aussehen:

    Die Parameter wären 1 Video-URL (samt VPID), 3 Audio-URL (samt 3 APID), die TSID, SID, Name des Kanals. Es kann aber auch nur eine URL sein, oder eine Video- und 1 oder 2 Audio-URL.

    Das alles als Parameter in einem Script, das die verschiedenen Möglichkeiten berücksichtigen muss, halte ich für nur schwer lesbar.


    Der vlc Aufruf ist zwar kleiner, aber gerade für Videostreams ist FFmpeg stabiler und schneller. Für Radio-Kanäle ist vlc unschlagbar schnell.

    Code
    vlc -I dummy -v \
      --network-caching=4000 \
      --live-caching 2000 \
      --http-reconnect \
      --http-user-agent=Mozilla/5.0 \
      --adaptive-logic highest https://kikageohls.akamaized.net/hls/live/2022693/livetvkika_de/master.m3u8 \
      --sout "#standard{access=file,mux=ts{use-key-frames,pid-video=100,pid-audio=200,pid-spu=4096,tsid=2850},dst=-}"


    Dann hatte ich überlegt für jede Kombination Video/Audio ein eigenes Script, das dann jeweils übersichtlicher ist, aber die Wartung wäre dann viel anstrengender.


    In einem Script gibt es dann auch das Problem, daß mit Sonderzeichen umgegangen werden muss. Aktuell nutze ich ein Array von Parametern und umgehe das Problem damit, aber falls nur ein String ermittelt wird, müsste das Script mit den Zeichen selbst umgehen können bzw. diese maskieren.


    Mir fällt da keine geschickte und pragmatische Lösung ein. Die Kombination flexibel/User-freundlich macht mir hier Probleme. Gibt es Ideen oder Anregungen?

    Bis auf die Fehlermeldungen wirkt der VDR beim Umschalten und im Menü nur leicht träger

    Bist du sicher, daß es Fehlermeldungen sind? Für mich sieht das eher so aus, als ob der Log-Level zu hoch gesetzt wurde.

    Was sagt denn

    Code
    grep LogLevel /etc/epgd/epgd.conf

    Und der Start Parameter

    Code
    -l <log-level>  set log level


    Edit:

    Darauf muss man erst kommen. Eloquence. Aber meine Vermutung stimmt wohl. Du hast irgendwo den Debug-Level eingestellt:

    Code
    tell(eloDebug, "Statement '%s' with (%ld) in parameters and (%d) out bindings prepared",
            stmtTxt.c_str(), mysql_stmt_param_count(stmt), outCount);

    Aber warum werden die Variablen nicht in die Funktion übernommen, wenn sie außerhalb definiert sind?

    Das scheint an der Reihenfolge der Aufrufe zu liegen. Erst wird das package.mk ausgewertet und die Abhängigkeiten bestimmt, die zuerst gebaut werden. Aber die Variable auf CEF hat erst nach dem Bau bzw. der Installation von CEF einen gültigen Wert, wird aber schon vorher gesetzt und nicht neu bestimmt. Deshalb auch das '--' im Link. Die Variable ist einfach leer. '-${CEF_VERSION}-'.

    Ich habe auch etwas gegrübelt und versucht herauszufinden, woher der falsche Link kommt.

    Ich vermute, da gibt es noch einen falschen Link im Build-Verzeichnis, der nicht automatisch korrigiert wird.


    Gründliche Lösung:

    Code
    ./clean-package.sh _cef
    ./clean-package.sh _cefbrowser
    
    Build starten...


    Weniger gründliche Lösung, die aber auch funktionieren kann:

    Code
    cd CoreELEC
    PROJECT=Amlogic-ce ARCH=arm DEVICE=Amlogic-ng scripts/clean _cef
    PROJECT=Amlogic-ce ARCH=arm DEVICE=Amlogic-ng scripts/clean _cefbrowser
    
    Build starten...


    Hintergrund: Ich vermute in CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/build/_cefbrowser-a43ec12d0e8e11a8f362b4f9cb6391424eb500a4/subprojects einen toten Link von cef der auf irgendwas mit ...cef--arm geht. Zwischen den beiden '-' sollte eigentlich die Versionsnummer stehen.

    Ein einfaches Löschen des Links, löst leider kein Rebuild aus, deshalb eine der beiden "cleans" von oben.

    ../meson.build:38:17: ERROR: Neither a subproject directory nor a cef.wrap file was found.

    Ich kann das nachvollziehen und suche gerade das Problem. Primärproblem ist aktuell _cef und nicht _cefbrowser.


    edit sagt:

    Die Reihenfolge der Variablen Initialisierung war nur suboptimal. Das hat jetzt nichts mit dem erwähnten Commit zu tun und mich wundert es, warum es nicht früher aufgefallen ist.

    das Löschen des Build Verzeichnisses hat nichts geholfen; da kommt wieder der gleiche Fehler.

    Das hat nicht geholfen? Welches Problem ist da denn nun wieder?


    WARNING Incorrect checksum calculated on downloaded file: got bca9a584a8da64d8dff50082a06f6cea26fb735f74924afc6d01ae6be7a75885 wanted fc1b9ed57f4cda51c52ec9b3b012f6973bd8d80fb70f363c5ca2754342389eb1

    Mein Lieblingsfehler. Eine falsche Checksum in der package.mk :(

    Wenn du den patch nach patches/CoreELEC/coreelec-22 kopierst, sollte zumindest das Paket bauen.

    json-c-checksum.patch.txt

    Und das .txt entfernen.


    Löscht du eigentlich das sources Verzeichnis gleich mit oder sicherst du das vor dem Löschen? Das spart enorme Downloadzeit und Downloadfehler sollten reduziert werden.



    Edit:

    Der Precache der Sources schlägt ziemlich fehl. Offensichtlich gibt es da Probleme. Unter anderem eben auch json.-c

    Precache Action

    ich hab nochmal ein Build mit dem aktuellen Stand gemacht.
    CE21-ng läuft fehlerfrei durch, bei CE22-no bekomme ich diesen Fehler:

    Ich nehme an, du hast den Build vorher nicht gelöscht. Ich hatte mit Python auch meine Probleme und nur ein echter neuer Build hat da geholfen :(


    In CE-20 kamen schon lange keine Updates (abgesehen von VDR+Plugins) mehr rein, CE-21 hält sich auch in Grenzen, aber gerade CE22-no ist in Bewegung und ich hoffe, daß irgendwann ein Stand erreicht ist, der produktiv nutzbar ist.

    Den tv Branch habe ich in den master Branch gemerged. Hinzugekommen sind 2 neue Plugin Parameter, mit den Funktionalität abgeschaltet werden kann, falls dies gewünscht ist:

    Code
    -s/--disable-svdrp   Schaltet die SVDRP Bridge ab
    -o/--disable-osd     Schaltet die OSD/TV Funktionalität ab

    Man kann auch beide Parameter gleichzeitig nutzen, nur wäre es dann eigentlich sinnvoller, das Plugin überhaupt gar nicht erst zu laden.

    This one, no sound

    It looks like a problem with libdvbtsi. There exists many errors (probably for each segment):

    Code
    [00007f70cc009a70] ts demux error: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 15) for PID 0
    [00007f70cc009a70] ts demux error: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 15) for PID 480

    And this seems to disturb the encoding, especially audio.


    There exists so many possible command line options and perhaps some channels works better with other options than the default. In the plugin webbridge i call a script to get the whole command line for transcoding depending on the channel itself. This could be also a solution here: Call a script and get the command line and if the channel depends on special configuration, then return another command line. Another idea is a configuration file which could contains command lines for a configured channel. I'm not sure, which idea is better.

    The main problem is the parameter list. Currently many pids from channels.conf and the channel name is used in the command line and this should be recognized.

    Im tv-Branch habe ich einige Änderungen vorgenommen:

    - tiny-process wurde ersetzt durch pstreams

    - Aufnahmen werden abgespielt. Allerdings machen Sprünge in den Aufnahmen noch Probleme. Ich weiß noch nicht, wie ich FFmpeg und videojs davon überzeuge, daß alles so seine Richtigkeit hat.


    Bei den Scripten, die aufgerufen werden um den eigentlichen FFmpeg Aufruf zurückzugeben, hatte ich Bedenken. Falls jemand die Script ändern kann, kann alles im System aufgerufen werden. Aber falls jemand tatsächlich die Schreibrechte auf die Scripte hat, muss er die Scripte dazu nicht ändern, sondern kann direkt alles machen, was dem User gestattet wurde.

    Liege ich da falsch oder sieht jemand Bedenken, an die ich nicht gedacht habe? Zur Sicherheit würde ich sowieso empfehlen, die Schreibrechte einzuschränken. 777 war noch nie eine gute Idee.


    Ich denke darüber nach, dasselbe auch in iptv zu machen. Mit pstreams habe wesentlich mehr Kontrolle über den Prozess und FFmpeg/vlc Aufrufe konfigurierbar zu machen ist auch keine schlechte Idee.

    du kannst die beiden patches wieder raus nehmen. Portisch hat die pull-requests angenommen und sie sind nun im Kernel 5.4.210 und in den media-modules-aml.

    Tut mir Leid das da im Moment noch so viel Bewegung drin ist und du immer hinter laufen musst.

    Beide Patches sind wieder weg. Im Moment herrscht sowieso ein Flut an Patches. rell hat schon angefangen viele Patches zu löschen, die nicht mehr notwendig sind. Ich kann nur hoffen, daß der Build mal langsam wieder übersichtlich wird und auch stabil funktioniert.