softhdodroid: nach Wechsel von kodi zu vdr bleibt Bild manchmal schwarz

  • mal eine Frage an die Nutzer von amlogic-Boxen (hallo beta , hallo jojo61 :) )...

    Es kommt bei mir leider immer wieder vor, dass bei der Rückkehr von kodi zu vdr das Bild schwarz bleibt. Nur das OSD und der Ton geht noch. Ich habe den Eindruck es passiert dann, wenn die Box sehr lange (über Stunden) im kodi-Modus blieb, ohne dass dort etwas abgespielt wurde.

    Die Ausgabe von journalctl liefert dann nach Rückkehr zu vdr einen fortwährend geloggten Kernel error: vf_notify_receiver, fail to get receiver


    Meine Umgebung ist CoreELEC mit vdr in chroot nach Rezept von beta. Ich habe dabei das zum Start von kodi notwendige Killen des looper-Scriptes sowohl über das externalplayer-Plugin versucht (Vorteil: vdr geht dabei in Playmode pmNone) als auch über einen Befehl in der commands.conf.


    Geht man mit dem Schwarzbild zurück in kodi, läuft dort die Bildwiedergabe einwandfrei. Erneute Rückkehr zu vdr - weiterhin kein Bild. Erst ein vdr restart aus dem Einstellungsmenü heraus behebt das Problem. Blöd nur, wenn gerade eine Aufnahme läuft.


    Habt Ihr das auch schon mal beobachtet? Kann es sein, das kodi vielleicht beim Beenden die Ressourcen nicht freigibt und eine längere Wartezeit zwischen systemctl stop kodi und dem attachen von softhdodroid notwendig ist? Wo baue ich das im softoggle-Script am besten ein?


    Da sind ja schon zwei sleeps drin, aber so ganz habe ich den Ablauf noch nicht verstanden.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Wenn Du eien sleep nach Kodui machen möchtest dann baue ihn nach

    Code
    systemctl mask kodi

    ein.

    Ob das allerdings etwas bringt erscheint mir zweifelhaft. Kodi bastelt laufend an den Grafik einstellungen und ich hatte schonmal änderungen eingebaut damit das Bild nach Kodi wieder kommt. Könnte also sein das Kodi hier wieder irgend etwas "optimiert" hat. Könnte auch an den Änderungen mit dem Schwarzbild beim umschalten liegen.

  • Genau an der Stelle hatte beta ursprünglich einen sleep von 9 Sekunden vorgesehen. In seinem letzten HowTo sind es jetzt noch 3 Sekunden. Bei mir saß der sleep an der falschen Stelle. Und anstelle von 10 Sekunden am Anfang des Scripts hatte ich nur 5 s. Mal sehen, ob das jetzt mit dem letzten Script von beta stabiler läuft.

    Am Schwarzbild beim Umschalten dürfte es nicht liegen. Zum einen kommt das ohne Verwendung des externalplayer-Plugins gar nicht zum Einsatz, da vdr dann gar nicht auf Playmode 0 schaltet. Zum anderen habe ich geprüft, dass im Fehlerfall der Wert von /sys/class/video/disable_video auf 0 stellt - daraus resultiert das Schwarzbild also nicht.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Der Fehler tritt weiterhin regelmäßig auf. Die volle Bezeichnung im log ist

    Code
    kernel: Error: vf_notify_receiver, fail to get receiver of provider vdec.mpeg12.01

    Ich habe mal /sys/class/* vor dem Wechsel zu kodi und nachher kopiert und ein diff gemacht. Darin fallen mir diese Unterschiede auf:


    Diff
        diff -ur class_vorher/video_poll/primary_src_fmt class/video_poll/primary_src_fmt
    --- class_vorher/video_poll/primary_src_fmt     2023-04-14 12:39:29.000000000 +0200
    +++ class/video_poll/primary_src_fmt    2023-04-14 12:43:08.000000000 +0200
    @@ -1 +1 @@
    -src_fmt = SDR
    +src_fmt = invaild

    Vielleicht hilft das weiter?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Nachtrag: während das Vollbild im Fehlerfall schwarz ist (nur OSD ist noch da) , kann ich PIP aktivieren und sehe dann ein Bild im kleinen PIP-Fenster

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Danke, ich werde es beobachten.

    Fürs Protokoll: Da es mit dieser Änderung eine unschöne Verzerrung des CoreELEC-Logos beim Starten von vdr gibt (und manchmal auch des Kodi-Bildes bei Rückkehr zu vdr) habe ich noch zusätzlich dies bei mir eingebaut:


    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ist leider gerade wieder aufgetreten. Ich glaube, den Fehler habe ich erst, seit ich den Multidecode-fähigen Kernel von Zabrimus habe, der PIP unterstützt.

    Ein CoreELEC-Entwickler hatte letztes Jahr erläutert, warum das in CE nicht standardmäßig aktiv ist: https://discourse.coreelec.org/t/multidecode/18514/4

    Zitat

    the Kernel get confused about the streams as Kodi open/close stream handling is faulty. The results are black screen because Kernel display stream two and Kodi feeds stream one.

    wenn der Fehler in Kodi liegt, kann man wahrscheinlich nicht viel machen?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Das klingt gar nicht gut. Die einzig wirklich sichere Lösung wäre es, dann den Disable-Multidecode-Patch nicht mehr zu löschen um das vorherige Verhalten wieder herzustellen. Allerdings fliegt dann auch PIP wieder weg.

    In Kodi kann man das Problem wohl z.B. auch im pvr iptvsimple Addon provozieren. Wobei die Frage wäre, was das Addon kann, was nicht auch im VDR selbst funktioniert.

    Zu beobachten scheint das Problem beim Wechsel von Kodi -> VDR mit einem Blackscreen und durch einen Restart von VDR auflösbar zu sein.


    Damit stellen sich mir mehrere Fragen:

    Was ist denn die gewünschte Default-Konfiguration? PIP möglich oder nicht? Selbstbauer können dann die eine oder andere Variante auswählen.

    Gibt es einen Weg Kodi vorzutäuschen, es gäbe nur einen Decoder? Unabhängig von der tatsächlichen Anzahl?

    Warum hilft ein VDR Neustart überhaupt? Es muss dann doch irgendwas im Ausgabeplugin abgeräumt werden, oder sehe ich das falsch?

    Taucht der Fehler eigentlich auch auf, wenn man Fastswitch Kodi <-> VDR nicht aktiviert? Also statt einem Attach/Detach einen echten VDR Neustart macht? Obwohl das keine Lösung ist, wenn es um Aufnahmen im Hintergrund geht.

    Oder kann man "höhere" Decoder nur für das Ausgabeplugin nutzen und den ersten rein für Kodi reservieren?

  • Ich wüsste nicht was ich bei einem attach anderes mache als bei einem neustart des VDR. Letztlich wird alles über das vfm gesteuert und das erneuere ich beim start/attach. Evtl. muss man den vdr nach beenden des Kodi neu durchstarten. Dann würde er während der Kodi läuft im Hintergrund noch aufnehmen können, aber beim beenden des Kodi durchgestartet werden. Also etwas wie systemctl restart vdr in dem looper batch.

  • Mir fällt auf, dass in VideoInit das Löschen mit "rm default" erfolgt:

    Code
        amlSetString("/sys/class/vfm/map","rm default");
        sleep(2);
        amlSetString("/sys/class/vfm/map","add default decoder ppmgr deinterlace amvideo");
    
        amlSetInt("/sys/class/graphics/fb0/free_scale", 0);
        amlSetString("/sys/class/graphics/fb0/free_scale_axis", fsaxis_str);
        amlSetString("/sys/class/graphics/fb0/window_axis", waxis_str);
        amlSetInt("/sys/class/graphics/fb0/scale_width", OsdWidth);
        amlSetInt("/sys/class/graphics/fb0/scale_height", OsdHeight);
        amlSetInt("/sys/class/graphics/fb0/free_scale", 0x10001);


    während in einer ähnlichen Stelle in VideoExit ein "rm all" gesetzt wird, wonach dann aber gleich wieder einiges geaddet wird:

    Stellt das wirklich den Standard-Zustand wieder her, oder entsteht hier vielleicht schon das Problem beim Wechsel zu kodi (und proviert dort die Nutzung zusätzlicher decoder-Instanzen)?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich wüsste nicht was ich bei einem attach anderes mache als bei einem neustart des VDR.

    Der Neustart des vdr öffnet das softhdodroid-Plugin nicht nur, sondern beendet es zunächst auch.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Einmal editiert, zuletzt von Dr. Seltsam ()

  • Bei einem detach mach ich auch alles zu. Da ist das Plugin faktisch beendet was den aml Teil angeht.

    Man könnte aber mal beim öffnen den Teil des restore vom exit einbauen. Dann sollte es egal sein wie Kodi es hinterlässt:


  • ja, aber dann kommt kodi und öffnet die ressourcen wieder. Nach Rückkehr von kodi hat die Hardware dann einen anderen Status als vorher.

    Ich meine mich zu erinnern, das im Fehlerfall auch ein erneutes DETA/ATTA das Bild nicht wieder hervorzauberte, was gegen meine Theorie spricht, dass ein "rm all" in VideoInit die Lösung sein könnte. Ich teste damit trotzdem mal.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • ist das nicht doppelt gemoppelt? Erst alles löschen, dann einen Teil wieder hinzufügen, erneut wieder löschen und hinzufügen?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Das rm default löscht nur die eine default route. Alles andere bleibt erhalten. Nur rm all löscht alle routen.

    Man könnte also oben das erste setzen dre default route weglassen weil sie weiter unten wieder gelöscht wird. Damit sieht das dann so aus

  • Ich teste jetzt so in VideoInit:


    Das blank schalten zu Anfang und Ende hilft, die Bildverzerrungen auszublenden.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich hatte so gehofft, dass es den Fehler behebt… aber leider ist er heute wieder aufgetreten. Ich werde jetzt als nächstes einen Kernel ohne multidecode verwenden.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Die einzig wirklich sichere Lösung wäre es, dann den Disable-Multidecode-Patch nicht mehr zu löschen um das vorherige Verhalten wieder herzustellen. Allerdings fliegt dann auch PIP wieder weg.

    Ich blicke da jetzt nicht ganz durch. In CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/build/media_modules-aml-c1e576514cdb075c541ae804b16f481fdb106083/drivers/frame_provider/decoder/utils/vdec.h steht #define MAX_INSTANCE_MUN 9.


    Ich finde nur einen Patch CoreELEC/projects/Amlogic-ce/devices/Amlogic-ne/packages/linux-drivers/amlogic/media_modules-aml/patches/ um das auf 1 zu setzen. Ich baue aber für amlogic-ng. In CoreELEC/projects/Amlogic-ce/devices/Amlogic-ng/packages/ finde ich keinen entsprechenden Patch. An welcher Stelle im build-Prozess wird denn für ng der disable-Patch gelöscht?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

Jetzt mitmachen!

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