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

Zabrimus · April 7, 2025 at 4:53 PM

Das ZDF machte mehr Schwierigkeiten, als angenehm war. Aus irgendwelchen Gründen holt der Browser die Daten des Requests nicht ab und der Request bleibt im Status "pending" hängen. Und dann geht nichts mehr. Ich hatte auch mit einer cURL basierten Lib probiert, ob es evt. am Netzwerk-Transfer liegt, aber selbst da passiert das. Eine Ursache und die passende Lösung habe ich nicht gefunden. Entweder mache ich etwas falsch, daß nur beim ZDF zum tragen kommt oder es gibt eine andere Ursache. Mysteriös....

Ich hoffe, einen Workaround gefunden zu haben, der aus 2 Teilen besteht:
1. Ich setze die Javascript Variable window.GLOBALS.noapicall = true; Damit verhindere ich den ZDF tokenTest, der sowieso aufgrund von CORS fehlschlägt, aber gerne mal in "pending" hängen bleibt.
2. Hier setze ich eine Eigenschaft des Browsers ein, die ich zufällig entdeckt habe. Bei einem Wechsel der Domain wird unter der Haube der Mainframe ausgetauscht (der alte gelöscht inkl. pending und ein neuer erstellt). Diesen Wechsel kann ich nicht explizit triggern, sondern nur über einen Umweg. Dazu lade ich eine Seite von localhost, fange den Request aber ab, bevor er tatsächlich erzeugt wird und gebe HTTP 404 zurück. Das reicht schon, um den Mainframe auszutauschen.

Bisherige Tests sind vielversprechend, es kann aber sein, daß evt. noch Stellen existieren, bei denen ich noch einmal zu Trick 2 greifen muss. Aber ich hoffe, das nicht nicht notwendig ist.

Taipan · April 8, 2025 at 11:35 AM

Nach Update und kurzem Test läuft das aktuell bei mir sehr schön rund und zügig - ist fest integriert im Wohnzimmer!

Danke an dieser Stelle Zabrimus für Deine unermüdliche Arbeit

jojo61 · April 9, 2025 at 10:00 AM

Ich schliesse mich Taipan an und auch hier läuft es nun schön rund. Auch der crash beim beenden ist nun weg.

Jetzt kann ich das produktiv System endlich updaten Super Zabrimus

Edit:

zu früh gefreut. Nach dem Update des produktiv Systems crasht es dort immer noch beim runterfahren.

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xef9ff1dc in BrowserClient::connect() () from /usr/local/lib/vdr/libvdr-web.so.6
[Current thread is 1 (Thread 0xedeff400 (LWP 4562))]
(gdb) bt
#0 0xef9ff1dc in BrowserClient::connect() () from /usr/local/lib/vdr/libvdr-web.so.6
#1 0xef9ff22c in BrowserClient::ping() () from /usr/local/lib/vdr/libvdr-web.so.6
#2 0xef9ff854 in BrowserClient::InsertHbbtv(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
from /usr/local/lib/vdr/libvdr-web.so.6
#3 0xef9b13f4 in cAIT::cAIT(unsigned char const*, unsigned short) () from /usr/local/lib/vdr/libvdr-web.so.6
#4 0xef9b1b50 in cAitFilter::Process(unsigned short, unsigned char, unsigned char const*, int) () from /usr/local/lib/vdr/libvdr-web.so.6
#5 0x0011619c in cSectionHandler::Action() ()
#6 0x00140238 in cThread::StartThread(cThread*) ()
#7 0xf544c714 in ?? () from /usr/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Zabrimus · April 9, 2025 at 6:21 PM

jojo61 Der Crash sollte aber diesmal nicht zuverlässig wiederholbar sein, oder?. Da muss es schon ein interessantes Timing geben.

Ich habe noch ein Sicherheitsnetz aufgespannt und hoffe, daß der Crash damit beseitigt ist.

jojo61 · April 9, 2025 at 10:52 PM

Wenn du nun noch VDR*Elec aktualisierst .......

clausmuus · April 16, 2025 at 3:07 PM

Ich habe ein Problem mit dem Build des aktuellen cefbrowser. Dieser versucht (anders als die Version vor einigen Wochen), eine sqlite Lib direkt nach /usr/lib/libsqlite3.a zu kopieren. Das scheitert natürlich, da ich ja nicht als root kompiliere. Das gleiche Problem tritt auch bei libthrift auf.

Seit meinem letzten Build hat sich die Version des sqlite Subprojektes geändert.

Kannst Du mir einen Tipp geben wie sich das beheben bzw. wieder zum alten Verhalten ändern lässt? Ich kenne mich mit dem meson Build überhaupt nicht aus.

Kompilieren und in Pakete verpacken tue ich das ganze per Yocto.

Der vollständige error Log sieht so aus:

Code

| Installing subprojects/sqlite-amalgamation-3490100/libsqlite3.a to /usr/lib
| Traceback (most recent call last):
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/site-packages/mesonbuild/mesonmain.py", line 194, in run
|     return options.run_func(options)
|            ^^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/site-packages/mesonbuild/minstall.py", line 873, in run
|     installer.do_install(datafilename)
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/site-packages/mesonbuild/minstall.py", line 553, in do_install
|     self.install_targets(d, dm, destdir, fullprefix)
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/site-packages/mesonbuild/minstall.py", line 750, in install_targets
|     file_copied = self.do_copyfile(fname, outname, makedirs=(dm, outdir))
|                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/site-packages/mesonbuild/minstall.py", line 430, in do_copyfile
|     self.copy2(from_file, to_file)
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/site-packages/mesonbuild/minstall.py", line 327, in copy2
|     shutil.copy2(*args, **kwargs)
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/shutil.py", line 475, in copy2
|     copyfile(src, dst, follow_symlinks=follow_symlinks)
|   File "/home/claus/mld-dev-6.5/build/tmp-glibc/work/core2-64-mld-linux/cefbrowser/git/recipe-sysroot-native/usr/lib/python3.12/shutil.py", line 262, in copyfile
|     with open(dst, 'wb') as fdst:
|          ^^^^^^^^^^^^^^^
| PermissionError: [Errno 13] Permission denied: '/usr/lib/libsqlite3.a'

Display More

Zabrimus · April 16, 2025 at 4:27 PM

Quote from clausmuus

Ich habe ein Problem mit dem Build des aktuellen cefbrowser. Dieser versucht (anders als die Version vor einigen Wochen), eine sqlite Lib direkt nach /usr/lib/libsqlite3.a zu kopieren. Das scheitert natürlich, da ich ja nicht als root kompiliere. Das gleiche Problem tritt auch bei libthrift auf.

Beide Libs sollten eigentlich gar nicht kopiert werden, da sie statisch gelinkt werden und sie nach dem Build nicht mehr gebraucht werden. Ich muss schauen, wie ich die Installation in den subprojects verhindere.

Ich kompiliere auch nicht als root und die Libs werden nach /usr/local/lib installiert. Aber da will ich die eigentlich auch nicht haben.

Der letzte Commit sollte die Installation verhindern. Du solltest vorher das Verzeichnis subprojects/sqlite-amalgamation-3490100 löschen, damit auch das neue meson.build verwendet wird. thrift wird mit cmake gebaut und die Änderung sollte sofort greifen.

clausmuus · April 16, 2025 at 10:50 PM

Super, dass ging ja schnell. Jetzt lässt sich der cefbrowser wieder bauen

Kannst due den thrift Fix auch noch im remotetranscode einbauen?

Zabrimus · April 17, 2025 at 7:22 AM

Quote from clausmuus

annst due den thrift Fix auch noch im remotetranscode einbauen?

Die Änderung für den remotetranscode wurde übernommen und committed.

clausmuus · April 18, 2025 at 12:31 AM

Ich hab hier noch einen Patch für den cefbrowser. Der alleine reicht aber nicht damit sich der Database Path per Option setzen lässt. Die Variable browserDbPath wird bisher gar nicht verwendet.

Diff

diff --git a/main.cpp b/main.cpp
index 8e0d68b..60929bf 100644
--- a/main.cpp
+++ b/main.cpp
@@ -115,7 +115,7 @@ void parseCommandLine(int argc, char *argv[]) {
     staticPath = getexepath();
     staticPath = staticPath.substr(0, staticPath.find_last_of('/'));

-    while ((c = getopt_long(argc, argv, "qc:l:z:fp:s:bu:", long_options, &option_index)) != -1)
+    while ((c = getopt_long(argc, argv, "qc:l:z:fp:s:bu:d:", long_options, &option_index)) != -1)
     {
         switch (c)
         {

Display More

Zabrimus · April 18, 2025 at 10:55 AM

Quote from clausmuus

Die Variable browserDbPath wird bisher gar nicht verwendet.

Danke. Die Änderungen dazu müssen in irgendeinem Branch versickert sein Ich check das...

Edit:
Jetzt weiß ich es wieder. Die Datenbank wird initialisiert, bevor die Commandline überhaupt gelesen wird. Dazu hatte ich damals die ENV Variable BROWSER_DB_PATH eingeführt, um das Problem zu lösen.
Ich habe den Parameter -d/--browserdb <path> jetzt vollständig implementiert. Die Auswertung von ENV bleibt erhalten um Bestandsinstallationen nicht zu stören, sobald aber -d verwendet wird, hat dieser Wert Vorrang.

clausmuus · April 18, 2025 at 11:35 AM

Hi,

~~und noch eines. Gestern war auch der Parameter -u wirkungslos. Das habe ich aber noch nicht genauer analysiert.~~

Das war voreilig. Es gibt nur eine Info, dass initial die default Werte genommen werden

LotharE · April 18, 2025 at 11:59 AM

Den UserAgent kann man in der Datei user_agent.ini pro Channel konfigurieren, siehe https://github.com/Zabrimus/cefbr…56e3644c356038e

Dadurch ist der Parameter -u dann vermutlich nutzlos.

clausmuus · April 18, 2025 at 12:03 PM

Ne, der Parameter macht schon Sinn. Denn da drüber lege ich fest, wo die user_agent.ini zu finden ist. Bei mir unter /etc da es sich ja um eine Konfigurationsdatei handelt, die der User ändern kann.

LotharE · April 18, 2025 at 12:09 PM

Stimmt, ist ja der Pfad und nicht der UserAgent selbst .

clausmuus · April 18, 2025 at 12:15 PM

Das mit den Optionen funktioniert so wie's ausschaut schon mal.

Jetzt habe ich aber das Problem, dass ich beim Start diese Meldung bekomme, und danach stürzt der cefbrowser ab:

[0418/121226.630101:ERROR:icu_util.cc(223)] Invalid file descriptor to ICU data received.

Ich werde erst heute Abend dazu kommen mir das genauer anzuschauen. Aber vielleicht hat ja schon einer von Euch eine Idee dazu...

Zabrimus · April 18, 2025 at 12:37 PM

Quote from clausmuus

[0418/121226.630101:ERROR:icu_util.cc(223)] Invalid file descriptor to ICU data received.

Das working-directory für den Start des Browsers muss das Installationsverzeichnis sein. Die ganzen libraries und sonstigen Dateien werden relativ dazu gesucht. Im Installationverzeichnis sollte auch die icudtl.dat vorhanden sein.

clausmuus · April 18, 2025 at 11:37 PM

Danke für den Tipp. Mein Fehler war, dass ich die Lib Dateien in einen getrennten Ordner verschoben hatte, und dabei nicht beachtet hatte, dass auch diverse andere Dateien im Libs Ordner gesucht werden, und nicht im statics Ordner. Jetzt startet der cefbrowser wieder.

Mir ist aber noch ein kleiner Fehler aufgefallen. In der main.cpp in Zeil 343 wird geprüft, ob die Option --config gesetzt ist. Zum einen wird dort die alternative Option -c ignoriert, zum anderen wird bereits in Zeile 205 geprüft, ob die config Datei erfolgreich geladen wurde. Die Prüfung in Zeile 343 ist daher vermutlich nicht notwendig.

reini-at · May 4, 2025 at 11:55 PM New

Auch von mir ein großes Dankeschön an die Weiterentwicklung, das läuft ja genauso gut, wenn nicht sogar besser, als auf mein etwas betagterer Fernseher

Wenn ich 2 VDR an mein Remotetranscode auf meinem server (mittels proxmox virtualisiert) anbinden möchte, starte ich das einfach 2x mit unterschiedliche sockets.ini? Der port auf dem remotetrans served ist der der in der sockets.ini definiert wird? Alternativ zieh ich sonst ein weiterer lxc hoch mit andere IP adresse..

Macht es sinn / ist es möglich / ist es sinnvoll das transcoding auf die gpu auszulagern, z.b. auf intel systeme?

Vielen Dank nochmal für die tolle arbeit, sowohl für hbbtv als auch VDR*Elec!!

Zabrimus · May 5, 2025 at 8:03 AM New

Quote from reini-at

Wenn ich 2 VDR an mein Remotetranscode auf meinem server (mittels proxmox virtualisiert) anbinden möchte, starte ich das einfach 2x mit unterschiedliche sockets.ini?

Den remotranscode hatte ich eigentlich mandantenfähig geplant (also beliebig viele VDR mit einem Transcoder). Allerdings habe ich das nie wirklich getestet und weiß deshalb gar nicht, ob das wirklich funktioniert. Und hier habe ich mittlerweile auch pro Client einen eigenen remotetranscoder.

Quote from reini-at

Macht es sinn / ist es möglich / ist es sinnvoll das transcoding auf die gpu auszulagern, z.b. auf intel systeme?

Der Transcoder liest auch eine codecs.ini ein, mit der die Parameter für ffmpeg etwas angepasst werden können. Z.B.

Code

[video]
codec_copy = h264,h265,hevc,mpeg2video
transcode = libx264 -preset ultrafast -crf 22

[audio]
codec_copy = ac3,aac,mp2
transcode = aac

codec_copy ist das schnellste Verfahren, weil kein wirkliches trancoding stattfindet, sondern nur das Containerformat (mp4 oder was immer da auftaucht) nach TS gewandelt wird, sofern der codec passt.

Participate now!