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

Zabrimus · 30. November 2023

Zitat von jojo61

Also das testen ist sschwierig. Bisher habe ich noch keine Werbung sehen können. Allerdings ist mir der cefbrowser schon ein paarmal bei SAT1 abgeschmiert mit

Irgendetwas ist null, obwohl das nicht sein darf. Die folgende Meldung 'MainFrame is null' habe ich nur eingebaut, um Fehler zu finden und nicht erwartet, das ich diese Meldung jemals zu sehen bekomme. Eigentlich darf diese gar nicht kommen, da das Plugin eine Seite anfordert und damit auf jeden Fall ein Frame existieren muss. Selbst wenn im Frame gar keine URL geladen werden kann und dieses leer ist. Ganz seltsam.

Aber so unterschiedliche Fehlerbilder sind ätzend. Hast du pi-hole oder einen anderen Blocker aktiv?

Zabrimus · 30. November 2023

Zitat von jojo61

So ich habe nun gesehen das das Video nicht zu langsam läuft sondern das ich keine Daten bekomme. Dann stockt das Video kurz und dann läuft es wieder weiter. Das ganze passiert so im Sekundentakt. Da ist wohl eine Wartezeit zugross

Ganz merkwürdig. Das FFmpeg liefert die Daten in Realtime (Parameter -re) und stocken kann das Video eigentlich nur, wenn entweder der Server die Daten zu langsam liefert oder der Weg vom Transcoder zum VDR (obwohl eher unwahrscheinlich) zu langsam ist.

jojo61 · 30. November 2023

Zitat von Zabrimus

Hast du pi-hole oder einen anderen Blocker aktiv?

Ja pi-hole ist aktiv für diesen Rechner. Das lustige ist das es eine Zeitlang ging und ich bei Sat1 und Pro7 testen konnte. Aber nach einiger Zeit ging es dann nichtmehr und ich habe immer diesen "MainFrame is null" bekommen. Evtl hat ja Pro7 meine IP gesperrt weil ich die Filme immer abgebrochen habe

Zitat von Zabrimus

Das FFmpeg liefert die Daten in Realtime (Parameter -re) und stocken kann das Video eigentlich nur, wenn entweder der Server die Daten zu langsam liefert oder der Weg vom Transcoder zum VDR (obwohl eher unwahrscheinlich) zu langsam ist.

Da muss ich noch weiter testen. Es könnte z.b. sein das du beim PlayTSPaket eine wiederholung machen musst, aber da zu lange wartest und dann mein Puffer leer läuft. Die Wartezeiten da sind ja bisher nur per "Daumen" eingetragen. Ausserdem ist mir da noch unklar ob Sat1 da evtl. in progressiv mit 25 Hz liefert. Zumindest mal progressiv scheint es zu sein. Das würde der softhdcuvid derzeit nicht richtig verarbeiten.

jojo61 · 30. November 2023

So heute geht auch Sat1 wieder. Und ich habe gerade gesehen das mein FFprobe kein https kann. Deswegen kam dann keine Werbung weil die mit https abgerufen wird Mühsam ernährt sich das Eichhörnchen.

PS: Und pi-hole musste ich auch abschalten. Aber das ist ja auch mal eine gute Nachricht weil ich dann MIT pi-hole kein Werbung bekomme

jojo61 · 1. Dezember 2023

Nächstes Problem gefunden. Bei SAT1 machst du zwischen der Werbung und dem "Hauptfilm" nur ein DeviceClear. Das reicht leider nicht. Ich bräuchte da ein Stop und Start. Das DeviceClear löscht zwar den VideoPuffer macht aber keinen reset auf den Stream. D.h. der FFMPEG Decoder wird nicht geschlossen. Wenn nun der Hauptfilm mit einer anderen Auflösung kommt merkt das keiner und es geht schief.

PS: Stop und Start sind bei dir wohl close und open des VideoDevices.

An dem Problem mit dem Videoruckeln arbeite ich noch. Ausserdem wundert es mich mit welch unterirdischer Auflösung da gearbeitet wird

Zabrimus · 1. Dezember 2023

jojo61 Das war wieder ein Schubs in die richtige Richtung.

Ich habe den Video-Wechsel überarbeitet: Nach dem Super-UHD-Werbevideo startet das eigentlich gewünschte Video auf S1P7. Die Auflösungen in den Mediatheken der Privaten sind eher bescheiden und grenzwertig.

Die Pause wurde auch überarbeitet. Der Transcoder hat schon beim Resume auf Seek auf die letzte Position gemacht, aber statt im Plugin zu versuchen, möglichst viel an Alt-Daten zu retten, wird ein DeviceClear gemacht und mit den frischen TS-Paketen gearbeitet.

Das Verhalten der langen Pause eines Videos muss ich noch untersuchen bzw. erstmal nachstellen.

Edit:

Ich weiß gar nicht, ob du da was machen kannst, aber bei meinen Tests ist mit der VDR einmal abgeschmiert mit dem folgenden Backtrace

Code

Thread 73 "video display" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff89ffb6c0 (LWP 334233)]
0x000000004015fc45 in ?? ()
(gdb) bt
#0  0x000000004015fc45 in  ()
#1  0x00007fffc69ef5d7 in  () at /lib/x86_64-linux-gnu/libnvidia-glcore.so.525.125.06
#2  0x00007fffc69f368a in  () at /lib/x86_64-linux-gnu/libnvidia-glcore.so.525.125.06
#3  0x00007fffc664f685 in  () at /lib/x86_64-linux-gnu/libnvidia-glcore.so.525.125.06
#4  0x00007ffff6fbe033 in render_pass_quad (flip=0, xcrop=0, ycrop=0) at /home/rh/idea/vdr-2.6.4/PLUGINS/src/softhdcuvid/shaders.h:445
#5  0x00007ffff6fc162a in CuvidMixVideo (decoder=0x555556dc7430, level=0) at video.c:3857
#6  0x00007ffff6fc1834 in CuvidDisplayFrame () at video.c:4455
#7  0x00007ffff6fc254e in CuvidSyncDisplayFrame () at video.c:4860
#8  0x00007ffff6fc392a in VideoHandlerThread (dummy=0x0) at video.c:5851
#9  0x00007ffff78a8044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#10 0x00007ffff792861c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) bt full
#0  0x000000004015fc45 in  ()
#1  0x00007fffc69ef5d7 in  () at /lib/x86_64-linux-gnu/libnvidia-glcore.so.525.125.06
#2  0x00007fffc69f368a in  () at /lib/x86_64-linux-gnu/libnvidia-glcore.so.525.125.06
#3  0x00007fffc664f685 in  () at /lib/x86_64-linux-gnu/libnvidia-glcore.so.525.125.06
#4  0x00007ffff6fbe033 in render_pass_quad (flip=0, xcrop=0, ycrop=0) at /home/rh/idea/vdr-2.6.4/PLUGINS/src/softhdcuvid/shaders.h:445
        va = {{position = {x = -1, y = 1}, texcoord = {{x = 0, y = 0}, {x = 0, y = 0}, {x = 1.40129846e-45, y = 0}, {x = 2.34379578, y = 0}, {x = -5.65841533e+33, y = 4.59163468e-41}, {x = 2.24207754e-44, y = 0}}}, {position = {x = -1, y = -1}, texcoord = {{x = 0, y = 1}, {x = 0, y = 1}, {x = 2.74091069e+15, y = 4.59163468e-41}, {x = -17269.7617, y = 4.59163468e-41}, {x = 1.40129846e-45, y = 0}, {x = 2.34375, y = 0}}}, {position = {x = 1, y = 1}, texcoord = {{x = 1, y = 0}, {x = 1, y = 0}, {x = 2.74091069e+15, y = 4.59163468e-41}, {x = 1.68155816e-44, y = 0}, {x = 2.34375, y = 0}, {x = 2.36650014e+13, y = 3.0611365e-41}}}, {position = {x = 1, y = -1}, texcoord = {{x = 1, y = 1}, {x = 1, y = 1}, {x = -3.07772633e-33, y = 4.59163468e-41}, {x = -14228.457, y = 4.59163468e-41}, {x = -6.15608743e-33, y = 4.59163468e-41}, {x = -6.15524107e-33, y = 4.59163468e-41}}}}
--Type <RET> for more, q to quit, c to continue without paging--c
        n = 3
        e = 0x7ffff6feed90 <vertex_vao+48>
#5  0x00007ffff6fc162a in CuvidMixVideo (decoder=0x555556dc7430, level=0) at video.c:3857
        current = 5
        y = 0
        xcropf = 0
        ycropf = 0
        texLoc = 3
        sd1 = 0x0
        sd2 = 0x0
#6  0x00007ffff6fc1834 in CuvidDisplayFrame () at video.c:4455
        last_time = 98428065220
        i = 0
        filled = 1
        decoder = 0x555556dc7430
        valid_frame = 1
#7  0x00007ffff6fc254e in CuvidSyncDisplayFrame () at video.c:4860
#8  0x00007ffff6fc392a in VideoHandlerThread (dummy=0x0) at video.c:5851
        __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140735508625088, 6276316145025494464, -168, 11, 140737488344640, 140735500234752, 6276316145044368832, 6276058829981298112}, __mask_was_saved = 0}}, __pad = {0x7fff89ffaef0, 0x0, 0x0, 0x0}}
        __cancel_routine = 0x7ffff6fc3773 <exit_display>
        __cancel_arg = 0x0
        __not_first_call = 0
#9  0x00007ffff78a8044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735508625088, -6276074250819654208, -168, 11, 140737488344640, 140735500234752, 6276316145023397312, 6276057092481166784}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#10 0x00007ffff792861c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)

Alles anzeigen

jojo61 · 3. Dezember 2023

Zitat von Zabrimus

Ich weiß gar nicht, ob du da was machen kannst, aber bei meinen Tests ist mit der VDR einmal abgeschmiert mit dem folgenden Backtrace

Das könnte daran liegen das ich den Wechsel der Auflösung nicht mitbekommen habe. Dann stimmen natürlich die Framebuffergrössen in der GPU nicht mehr und beim Rendern fällt er hin.

Was mir sehr negativ bei S1P7 aufgefallen ist, ist das die in 25 fps und progressiv senden. Das kann der softhdcuvid überhaupt nicht und das habe ich auch nicht vor zu implementieren. Dann müsste ich jedes Frame doppelt an die Graka geben und den halben sync umbauen. Da wollte ich mal untersuchen ob der ffmepg nicht auch gleich die Framerate auf 50 fps anpassen kann. Das wäre dann viel einfacher.

jojo61 · 4. Dezember 2023

Ich bekomme mal wieder einen double free bei RTL:

Code

#0  0x00007fd0180d0cbb in raise () from /lib64/libc.so.6
#1  0x00007fd0180d2355 in abort () from /lib64/libc.so.6
#2  0x00007fd018116ae7 in __libc_message () from /lib64/libc.so.6
#3  0x00007fd01811eb6a in malloc_printerr () from /lib64/libc.so.6
#4  0x00007fd018120744 in _int_free () from /lib64/libc.so.6
#5  0x00007fd01259c99b in cVector<cOglPixmap*>::~cVector (this=0x7fcf50003280, 
    __in_chrg=<optimized out>) at /usr/src/vdr/vdr-2.6.4/include/vdr/tools.h:740
#6  cOglOsd::~cOglOsd (this=0x7fcf50003190, __in_chrg=<optimized out>) at openglosd.cpp:2040
#7  0x00007fd01259ca49 in cOglOsd::~cOglOsd (this=0x7fcf50003190, __in_chrg=<optimized out>)
    at openglosd.cpp:2045
#8  0x00007fd0093edc49 in WebOSDPage::~WebOSDPage (this=0x7fcf50001f80, 
    __in_chrg=<optimized out>) at webosdpage.cpp:114
#9  0x00007fd0093edcc9 in WebOSDPage::~WebOSDPage (this=0x7fcf50001f80, 
    __in_chrg=<optimized out>) at webosdpage.cpp:133
#10 0x00007fd0093c1da5 in cDummyOsdObject::~cDummyOsdObject (this=0x116c5b60, 
    __in_chrg=<optimized out>) at dummyosd.h:10
#11 cDummyOsdObject::~cDummyOsdObject (this=0x116c5b60, __in_chrg=<optimized out>)
    at dummyosd.h:11
#12 0x00000000004800e1 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1284

Alles anzeigen

RTL geht ansonsten aber recht gut.

S1P7 ist immer noch eine grosse Baustelle. Allerdings funktioniert nun der Videowechsel. Dafür dauert es aber ca.5 sekunden bis ich einen Film mit Menü abbrechen kann.

Die Pause scheint nun auch gut zu funktionieren. Es geht vorran

jojo61 · 5. Dezember 2023

Die patches zum Fastscale funktionieren leider nicht. Das web Plugin lässt sich trotz VDR patch nicht mit dem ENABLE_FAST_SCALE=1 compilieren.

rell · 5. Dezember 2023

Zitat von jojo61

Die patches zum Fastscale funktionieren leider nicht. Das web Plugin lässt sich trotz VDR patch nicht mit dem ENABLE_FAST_SCALE=1 compilieren.

Hast du ein Log, warums scheitert? Hier baut es...

jojo61 · 5. Dezember 2023

Code

g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/src/vdr/include -I/usr/include/GraphicsMagick -c -DPLUGIN_NAME_I18N='"web"' -DENABLE_FAST_SCALE -I. -Ithirdparty/mINI-0.9.14/src/mini -o webosdpage.o webosdpage.cpp
webosdpage.cpp: In member function ‘bool WebOSDPage::scaleAndPaint(uint8_t*, int, int, int, int, int, int)’:
webosdpage.cpp:313:90: error: no matching function for call to ‘cImage::cImage(cSize, const tColor*, double&, double&)’
  313 |         const cImage recImage(cSize(width, height), (const tColor *)image, scalex, scaley);
      |                                                                                          ^
In file included from /usr/src/vdr/include/vdr/dvbsubtitle.h:15,
                 from /usr/src/vdr/include/vdr/device.h:15,
                 from webosdpage.cpp:1:

Das ist mit den patches aus dem GIT

rell · 5. Dezember 2023

Fehlt da evtl. der Patch fürs plugin selbst?

VDRSternELEC/packages/vdr/_vdr-plugin-web/patches/0001-scale.patch at master · Zabrimus/VDRSternELEC

Contribute to Zabrimus/VDRSternELEC development by creating an account on GitHub.

github.com

Zabrimus · 5. Dezember 2023

Zitat von rell

Fehlt da evtl. der Patch fürs plugin selbst?

Mist.

rell ich habe deine Patches für die Output-Devices und den VDR mit in das Repository zu dem web-Plugin gepackt um das Ganze noch "offizieller" zu machen und nicht nur in VDR*ELEC zu verstecken.

Allerdings habe ich vergessen, das Plugin selbst zu patchen.

Da gibt es jetzt einen Mismatch. Das muss ich korrigieren.

Edit: Dein Patch für das Plugin ist nun offiziel im Git eingecheckt. Jetzt passt alles wieder. Nur muss VDR*ELEC noch angepasst werden, bei einem Update.

jojo61 · 6. Dezember 2023

Ich habe das nun mal mit dem softhdodroid ausprobiert und hatte noch ein paar segfaults. Deswegen habe ich den patch für das softhdodroid noch etwas überarbeitet und nun scheint es zu laufen. Wirklich flott nun. Allerdings gibt es noch andere Probleme:

- wenn ich ein laufendes Video mit Menü abbreche dann dauert es sehr lange bis das Menü kommt und TV wieder erscheint. Ich vermute das das web plugin im PlayPacket hängt und versucht noch restliche Daten los zu werden (bis zum timeout).Hier müsste wohl noch ein Test rein ab Abgebrochen wurde. Du wartest da 500 Millisekunden mal 10, das ist eh nicht so perfekt. Besser wäre eher 50 mal 100 oder 5 mal 1000. Bei 500 ms läuft evtl. der Puffer im Ausgabeplugin schon leer bevor du es wieder versuchst. Das sind immerhin 25 Frames.

Ausserdem meint das web plugin nachdem ich einen Film mit Menü abbreche das der Browser nicht mehr da ist.

- dann hatte ich noch einige Segfaults aber habe keine Dumps. Das werde ich weiter beobachten und hoffentlich dumps bekommen.

Die Änderungen wegen dem scaling habe ich als neuen Patch hier angehängt.

PS: man sollte noch Erwähnen das man alle plugins mit OSD neu compilieren muss wenn man den VDR patched. (z.b. Teletext)

Zabrimus · 8. Dezember 2023

Zitat von jojo61

Ich habe das nun mal mit dem softhdodroid ausprobiert und hatte noch ein paar segfaults. Deswegen habe ich den patch für das softhdodroid noch etwas überarbeitet und nun scheint es zu laufen. Wirklich flott nun.

Ich habe mal die Patches verglichen um herauszufinden, ob es evt. Auswirkungen für die anderen Ausgabe-Plugins gibt. Mal abgesehen davon, daß statt den Default-Parametern für die Skalierungsfaktoren nun explizite Werte gesetzt werden finde ich dieses interessant:

Code

+    if (x + width * scaleX > VideoWindowWidth) {
+    printf("Scaling over the Width edge %f\n",x + width * scaleX);
+         scaleX = 1.0;
+    }
+    if (y + height * scaleY > VideoWindowHeight) {
+    printf("Scaling over the Height edge %f\n",x + height * scaleY);
+         scaleY = 1.0;
+    }

Ist das tatsächlich passiert? Das durch die Skalierung eine zu hohe Breite/Höhe entstanden ist? Zumindest im web-Plugin wird der Skalierungsfaktor genau an den Videogrenzen ausgerichtet. Ich kann mir nur vorstellen, daß durch Rundungen ein zu hoher Wert entsteht. Aber wird dann nicht einfach ein Crop gemacht?

Zitat von jojo61

Allerdings gibt es noch andere Probleme:
- wenn ich ein laufendes Video mit Menü abbreche dann dauert es sehr lange bis das Menü kommt und TV wieder erscheint. Ich vermute das das web plugin im PlayPacket hängt und versucht noch restliche Daten los zu werden (bis zum timeout).

Nicht ganz. Der Browser wartet so lange, weil ich erkennen muss ob in der Seite ein StopVideo/StartVideo unmittelbar (oder eben in einer bestimmten Zeit) hintereinander kommen. Dann darf ich beides nicht ausführen, sondern muss ein Reset machen. Ansonsten gibt es eine Race-Condition im Plugin mit Konstruktor/Destructor/Attach/Detach.

Das ist auch noch auf meiner TODO-Liste, daß ich im Plugin erkennen muss, daß das Menu aufgerufen wird. Der Key selbst wird nicht an das Plugin durchgereicht, also muss ich etwas anderes finden.

Zitat von jojo61

PS: man sollte noch Erwähnen das man alle plugins mit OSD neu compilieren muss wenn man den VDR patched. (z.b. Teletext)

Ja stimmt. Ich bin da wohl mittlerweile von VDR*ELEC verwöhnt, weil der Build die Abhängigkeiten automatisch erkennt und dann auch alles passende dazu neu baut.

Also:
Nach Anwenden des VDR Patches müssen alle Plugins mit einem OSD neu gebaut werden.

jojo61 · 8. Dezember 2023

Zitat von Zabrimus

Mal abgesehen davon, daß statt den Default-Parametern für die Skalierungsfaktoren nun explizite Werte gesetzt werden finde ich dieses interessant

Ich hatte mehrmals einen "Bus error" und vermutete das es evtl. an Rundungsfehlern liegt. Deswegen habe ich es als Sicherheit eingebaut. Auch die default Werte sind so entstanden. Was genau den "Bus Error" ausgelöst hat kann ich nicht sagen aber so läuft es nun

Zitat von Zabrimus

Nicht ganz. Der Browser wartet so lange, weil ich erkennen muss ob in der Seite ein StopVideo/StartVideo unmittelbar (oder eben in einer bestimmten Zeit) hintereinander kommen.

Das dauert aber so ca. 5 sekunden bis nach dem drücken von Menü das Menü dann auch kommt. Aber das Video wird sofort gestoppt.

Und danach hat das Plugin vergessen das der Browser da ist

PS: hattest du bei dem Resume ein StopVideo/StartVideo (kein Reset) eingebaut ? Ich hatte gestern mal wieder nach einer längeren Pause den Effekt das es danach zwar anlief aber stotterte. Das ging erst weg als ich den Film komplett abgebrochen habe und dann neu gestartet habe.

Zabrimus · 8. Dezember 2023

Mittlerweile weiß ich, wo die Bremse liegt, wenn man das Menu aufruft: Im Transcoder.

Noch habe ich keine Idee, woran das liegt und wie das umgegangen werden kann, aber der kill von ffmpeg dauert so lange bzw. funktioniert nicht.

Und wieder ein Mysterium....

Achja. Das der Browser nicht mehr erreichbar ist, habe ich auch. Ich hoffe dafür eine Lösung zu finden.

Zabrimus · 9. Dezember 2023

Faszinierend. Es gab einen Deadlock über alle 3 Komponenten, der nur durch einen Timeout aufgelöst wurde.

Das Plugin und der Transcoder wurden aktualisiert und jetzt schwuppt das. Den fehlenden Browser habe ich seitdem nicht mehr produzieren können. Ich hoffe, das Problem wurde "nebenbei" gefixed.

Zabrimus · 17. Dezember 2023

Ich bin sehr unzufrieden

Es gibt einen Unterschied im Verhalten der Menutaste zwischen der Entwicklungsmaschine und dem N2+ (VDR*ELEC). Die Plugins bekommen die Menutaste nicht, also kann es meines Erachtens nur an einem Patch liegen. Auf jeden Fall ist das unterschiedliche Verhalten alles andere als erwünscht und richtig ätzend.

Enwicklungsmaschine:

- Film in der Mediathek wird abgespielt

- Menu-Taste und das web-Plugin wird beendet, das TV-Bild kommt

N2+:

- Film in der Mediathek wird abgespielt

- Menu-Taste, aber das web-Plugin läuft weiter. Das Video (im Skindesigner) wird skaliert weiter abgespielt und ich habe dann den Menu-Eintrag "Aufzeichnung beeenden" oder ähnlich.

- Das Problem zieht sich dann sogar durch. Z.B. Tagesschau auf ARD. Dann sind plötzlich beide OSD (web + VDR) flackernd sichtbar und es schwer, da wieder raus zu kommen.

Auf der Entwicklungsmaschine kommt bei der Menu-Taste das:

Code

Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Destruct WebOSDPage, osdMode 1
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Delete Player...
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Activate video player: Nein
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Detaching HbbTV ait filter from device 2
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Attached HbbTV ait filter to device 2, vdrDev=1 actDev=2, Sid=0x283d

Und damit wird das web-Plugin beendet und dem VDR wieder die Kontrolle übergeben. So wie es sein sollte. Auf dem N2+ kommt die Ausgabe nicht, so gar nicht, es gibt einfach nix. Das web-Plugin läuft weiter - in Konkurrenz zum VDR.

Edit:

Das Problem tritt auch ohne alle Patches auf. Die Plugins wurden auch auf ein Minimum reduziert, aber das brachte auch nichts.

Was kann denn noch das unterschiedliche Verhalten provizieren?

Zabrimus · 17. Dezember 2023

Meine Güte. Ist das lang her. Jetzt weiß ich auch wieder, warum ich das DummyOSD im web-Plugin eingeführt hatte. Das weiß ich jetzt wieder, nach langem suchen und testen

Wenn das web-Plugin mit dem Parameter

-o oder --dummyosd

gestartet wird, dann funktioniert alles so wie gewünscht.

Also falls jemand das Problem hat...An den Parameter denken. Gibt es Situationen, in denen das DummyOSD nicht gebraucht wird? Ansonsten würde ich das per Default einschalten und den Parameter entfernen bzw. unbrauchbar machen.

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

Jetzt mitmachen!

Teilen