hbbtv-Plugin

    Zitat von nobanzai

    Der zweite liegt daran, dass er nicht zum X Server connecten kann. Das ist kein schönes Verhalten, dann zu crashen, aber ok.

    Schön ist das gar nicht, aber der check findet entweder in Chromium oder CEF statt. Und da komme ich gar nicht ran. Fail-Fast bzw. Fast-Crash ist da wohl die Philosophie.


    Zitat von nobanzai

    [2021-04-22 23:20:36.569] [vdrosrbrowser] [trace] Send String to VDR, Message SEND_INIT
    [2021-04-22 23:20:36.575] [vdrosrbrowser] [trace] Received command from VDR: CHANNEL {"channelType":25,"ccid":"ccid://1.0","nid":1,"dsd":"","onid":1,"tsid":1010,"sid":11150,"name":"3sat HD","longName":"3sat HD","description":"OIPF (SD&S) - TCServiceData doesn't support yet!","authorised":true,"genre":null,"hidden":false,"idType":15,"channelMaxBitRate":0,"manualBlock":false,"majorChannel":1,"ipBroadcastID":"rtp://1.2.3.4/","locked":false}

    Das sieht doch gut aus? Der Browser sendet SEND_INIT an das Plugin und das Plugin antwortet mit CHANNEL. Die Kommunikation funktioniert. Geht denn jetzt etwas nicht?



    Zitat von msv

    [0423/150354.136224:ERROR:widevine_loader.cc(383)] Widevine CDM registration failed; Missing file ./widevine/libwidevinecdm.so

    Warum kommt die Meldung öfter? Ich habe meine lokale Einstellungen mal gelöscht und ich bekomme sie auch nur einmal.


    Kannst du mal versuchen, ob der Parameter:

    Code
    --no-sandbox

    beim Browser etwas bewirkt?


    Ich denke, ich werde einen weiteren Parameter im Browser implementieren, mit dem die Widewine-Initialisierung gar nicht erst versucht wird.


    Zabrimus

    Zitat von Zabrimus

    Das sieht doch gut aus? Der Browser sendet SEND_INIT an das Plugin und das Plugin antwortet mit CHANNEL. Die Kommunikation funktioniert. Geht denn jetzt etwas nicht?


    Zabrimus

    Eigentlich geht garnix 8-<

    Der Browser startet zwar im Terminal, aber wenn er von hbbtv gestartet wird, kommt doch wieder so eine Meldung:

    Code
    kernel: traps: vdrosrbrowser[1862] trap int3 ip:7fa1bda5711a sp:7ffd801dc260 error:0 in libcef.so[7fa1b9782000+a490000]

    Außerdem wird der VDR auch direkt unresponsive, sobald man einmal im Menü hbbtv gestartet und einen hbbtv Anbieter ausgewählt hat.

    Da kommt dann nicht mal die Anbieterseite, sondern das Fensehbild wird weiter angezeigt, allerdings stockend und stotternd.

    Und man kann auch kein Menü mehr bedienen, d.h. hbbtv auch nicht mehr beenden.

    An der Stelle hilft nur ein Neustart des VDR.

    Gerade noch festgestellt:
    Wenn ich den Browser mit der VDR-Kennung starte, kommt

    Er versucht, den Cache unterhalb des Installationsverzeichnisses anzulegen, was die VDR-Kennung natürlich nicht darf.

    Ich habe aber auch keinen Parameter gefunden, der ihm einen anderen Pfad für den Cache gibt.

    Zitat von nobanzai

    Er versucht, den Cache unterhalb des Installationsverzeichnisses anzulegen, was die VDR-Kennung natürlich nicht darf.

    Im Verzeichnisse 'cache' werden die Bewegungsdaten gespeichert (HTML und auch Cookies und dergleichen). Das ist leider im Browser hardcoded als direktes Unterverzeichnis.

    Aber wenn so darüber nachdenke, sollte der Pfad konfigurierbar sein. In /usr/local hat sowas eigentlich nix zu suchen.


    Natürlich kann du das Verzeichnis manuell anlegen und VDR Schreibrechte geben. Aber das wäre nur eine Notlösung.


    Zabrimus


    Das kam öfter ins Browserlogfile weil ich es mehrfach versucht habe...

    Ist aber jetzt durch die nachträgliche Installation vom Webvine-Plugin gelöst.


    gruß

    msv

    Zitat von Zabrimus

    Im Verzeichnisse 'cache' werden die Bewegungsdaten gespeichert (HTML und auch Cookies und dergleichen). Das ist leider im Browser hardcoded als direktes Unterverzeichnis.

    Aber wenn so darüber nachdenke, sollte der Pfad konfigurierbar sein. In /usr/local hat sowas eigentlich nix zu suchen.


    Natürlich kann du das Verzeichnis manuell anlegen und VDR Schreibrechte geben. Aber das wäre nur eine Notlösung.


    Zabrimus

    Das Verzeichnis gab es schon, gehörte aber root. Ich hab jetzt die Gruppe video berechtigt, in der auch der vdr hängt.

    Damit mault vdrosrbrowser nicht mehr und stürzt auch nicht mehr ab, wenn er vom hbbtv-Plugin gestartet wird.

    Eine Konfigurationsmöglichkeit wäre trotzdem das Beste.


    Bild oder sonstwas kommt leider trotzdem nach wie vor nicht. Es bleibt bei Anwahl eines hbbtv-Anbieters ein stotterndes VDR-Bild.

    Kann es sein, dass das softhdvaapi-Plugin, bzw. die GPU da irgendwie überfordert sind?

    Tja, also sieht wirklich so aus, als wäre die Intel-GPU mit softhdvaapi aktuell zu schwach für hbbtv, auch wenn das schon mal besser lief.

    Mit der Nvidia-Karte und dem softhdcuvid-Plugin bekomme ich zumindest wieder die Anbietermenüs.

    Einige Videos lassen sich dann auch im Fenster abspielen, aber nicht alle.

    Und sobald ich ein Video auf Fullscreen schalten will, hängt wieder alles und der Bildschirm wird schwarz.

    Passendes Log dazu:

    Zitat von nobanzai

    Das Verzeichnis gab es schon, gehörte aber root. Ich hab jetzt die Gruppe video berechtigt, in der auch der vdr hängt.

    Damit mault vdrosrbrowser nicht mehr und stürzt auch nicht mehr ab, wenn er vom hbbtv-Plugin gestartet wird.

    Eine Konfigurationsmöglichkeit wäre trotzdem das Beste.

    Die Repository-Version hat 2 neue Parameter

    Code
    --cachedir=<path>              Verzeichnis in dem der Browser seine Cache-Daten ablegen soll (Default: <browserpath>/cache)
--profiledir=<path>            Verzeichnis in dem der Browser seine Profile-Daten ablegen soll.  (Default: <browserpath>/profile)

    Die Pfade müssen absolut sein und nicht relativ.


    Zitat von nobanzai

    Bild oder sonstwas kommt leider trotzdem nach wie vor nicht. Es bleibt bei Anwahl eines hbbtv-Anbieters ein stotterndes VDR-Bild.

    Kann es sein, dass das softhdvaapi-Plugin, bzw. die GPU da irgendwie überfordert sind?

    Hmm. Du rufst das Plugin auf dann den Eintrag "Red Button" und damit funktioniert es nicht? Bei manchen Privatsendern wird nicht immer der "Red Button" angezeigt, aber mit dem Roten Knopf kommt man meist weiter.

    Das Erste/ZDF und Konsorten sind dabei wesentlich stabiler.


    Stotterndes Bild. Es werden nur Bilder in das OSD übertragen. Ich selbst habe es mit softhdcuvid und softhddevice getestet. softhdvaapi habe ich noch nicht getestet.


    Zabrimus

    Zitat von nobanzai

    Tja, also sieht wirklich so aus, als wäre die Intel-GPU mit softhdvaapi aktuell zu schwach für hbbtv

    Die GPU muss hier (im VDR) nicht viel machen, außer Bilder darstellen. Vielleicht ist da noch irgendwo ein Haken. Im Browser sieht es anders aus, da wird die GPU intensiver für das Rendering genutzt. Oder beide kommen sich in die Quere. Das kann ich gar nicht sagen.

    Zitat von nobanzai

    vdr[3210]: [3284] [hbbtv] Received Status: PLAY_VIDEO:
    vdr[3210]: [3284] [hbbtv] Received Status: STOP_VIDEO

    Das ist seltsam. Der Browser hat ziemlich schnell aufgehört das Video abzuspielen. Kannst Du mal im Browser den --trace Modus einschalten und im Log des Browser schauen?


    Was für ein Video ist das? Siehst Du das zufällig? MPEG-DASH? mp4? Evt. sogar live?


    Zabrimus

    Wenn die GPU nicht viel machen muss, wundert mich, dass die NVidia-Variante bis zumindest der hbbtv Seite klappt, die Intel nicht.

    Getestet habe ich es mit einem Video aus der ARD Mediathek.


    Wie gebe ich dem Plugin die Parameter für den Browser mit? Wenn ich sie einfach in die Plugin-Parameterliste schreibe, bekomme ich "[hbbtv] Error: Unknown command line parameter '?'".

    Ich habe meine kompilierte Developer-Version 1:1 auf mein Produktivsystem kopiert und dabei die libffmpeg.so aus installiertem Chromium in /usr/local/lib kopiert.

    Auf dem System läuft noch Ubuntu Bionic (18.04). Es läuft das softhddevice von https://github.com/ua0lnj/vdr-plugin-softhddevice. (Version ist alt:

    Tue Jun 30 19:48:39 2020 +1000)

    Die CPU ist noch ein

    Code
    Intel(R) Celeron(R) CPU J3455 @ 1.50GHz

    Und das Plugin läuft mit vaapi

    Also wirklich aktuell ist das System nicht. Aber der Browser und das Plugin funktionieren und es sind noch genügend CPU Reserven vorhanden. Ein Problem gibt es mit dem Video: Der 0-Punkt ist verschoben. Das Video beginnt nicht in der oberen linken Ecke, sondern mit einem größeren Versatz der x- und y-Achse. Das muss ich nochmal untersuchen.


    Aber generell gibt es erstmal kein Problem mit vaapi - aus meiner Sicht.

    Zitat von nobanzai

    Wie gebe ich dem Plugin die Parameter für den Browser mit? Wenn ich sie einfach in die Plugin-Parameterliste schreibe, bekomme ich "[hbbtv] Error: Unknown command line parameter '?'".

    Ein Fragezeichen? Meine Konfiguration auf dem Produktivsystem sieht so aus (vdr.config):

    Code
    [hbbtv]
-s
-p /home/vdr/build/Release/vdrosrbrowser
-c "--debug --user-data-dir=remote-profile --password-store=basic --fullscreen"
-l /home/vdr/build/Release/debug.log
-d :0

    Die Parameter für den Browser sind in " " eingerahmt.


    Zabrimus

    Ah, ich hatte übersehen, dass die Parameter für den Browser nochmals extra in Hochkommata stehen müssen.

    Das wird bei meiner Scriptlogik etwas "lustig".

    Aber so scheints zu klappen:

    Allerdings laufen dann da sechs Prozesse des Browsers und nur einer hat diese Parameter mitbekommen.

    Ist das ok?

    So, auf jeden Fall kommt hier im Anhang ein etwas längliches Log mit diversen Fehlern.

    Ansonsten bekomme ich auch auf de Bildschirm Fehler ala "unknown type error". Die sind aber nicht in einem Log zu finden, die könnte ich höchsten abfotografieren.

    Dateien

    vdrosrbrowser.txt 538,3 kB – 129 Downloads
    Zitat von nobanzai

    Allerdings laufen dann da sechs Prozesse des Browsers und nur einer hat diese Parameter mitbekommen.

    Ist das ok?

    Ja. Ich wusste erst nichts mit dem Parameter "--type=zygote" anzufangen und um ehrlich zu sein, so ganz sicher bin ich mir immer noch nicht. Auf jeden Fall erzeugt Chromium verschiedene Threads, die für bestimmte Aufgaben zuständig sind (Audio, Netzwerk, GPU, Browser,....). Wobei Threads mißverständlich ist, weil es eigentlich forks sind.

    Im Code ist es zum Teil spannend, weil ich nicht immer sicher bin, in welchem Thread (fork) ich mich befinde und verschiedene Funktionalitäten nur in bestimmten Threads erlaubt sind. Das ist mit ein Grund, warum ich es noch nicht geschafft habe, die Proxy-Konfiguration dynamisch per Sender zu gestalten: Mir gelingt es irgendwie nicht, in den richtigen Thread (fork) zu kommen.

    Zitat von nobanzai

    So, auf jeden Fall kommt hier im Anhang ein etwas längliches Log mit diversen Fehlern.

    Ansonsten bekomme ich auch auf de Bildschirm Fehler ala "unknown type error". Die sind aber nicht in einem Log zu finden, die könnte ich höchsten abfotografieren.

    Ich verstehe das nicht ganz. Wenn ich das richtig sehe, dann versuchst Du auf Arte ein Video zu sehen. Aber dann tauchen auf einmal Requests für ZDF auf. Ich muss mir das Log noch einmal in Ruhe zu Gemüte führen.

    Irgendwas ist da seltsam. Bist du auf dem Sender Arte oder ZDF, während die Arte Mediathek bzw. das Video gestartet wurde.


    Du siehst Fehlermeldungen auf dem Bildschirm???

    Könntest Du die die Dateien "content_trace_0*" im Release Folder mal löschen und den Fehler neu provozieren (auf möglichst kurzem Wege) und dann die "content_trace*" hochladen? Irgendwas stimmt mit der Seite bzw. dem Verändern der Seite nicht.


    Oder vielleicht auch den genauen Weg durch die Mediathek angeben, damit ich den nachvollziehen kann um den Fehler nachzustellen.


    Zabrimus

    Ich war auf Arte, habe dort den Red Button betätigt, dann erst die Arte Mediathek angewählt, später dann die ZDF Mediathek.

    Daher tauchen dort vermutlich beide auf.

    Das mit dem Trace mache ich demnächst mal.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden