RPI 3B+: Kein Bild nach dem Umschalten

  • Nach einem Upgrade meines RPI 3B+ habe ich ein interessantes Verhalten:

    Nach dem Start werden Bild und Ton ganz normal angezeigt. Nach dem Umschalten oder beim Abspielen einer Aufnahme gibt es dann jedoch kein Bild mehr, Ton gibt es aber sporadisch. Im Logfile findet sich die Meldung "ERROR: 1 TS packet(s) not accepted in Transfer Mode". Wenn der VDR ohne Reboot neu gestartet wird wiederholt sich das Verhalten.


    Der beim Upgade neu istallierte Kernel war 5.4.72-v7+, davor hatte ich 5.4.51-v7+.


    Ein paar weiter Experimente mit verschiedenen Kerneln via rpi-update führte zum Ergebnis, dass es bis zu folgender Änderung funktionierte:


    26620cc9a63c6cb9965374d509479b4ee2c30241 => ok

    Linux RPI-VDR 5.4.68-v7+ #1343 SMP Mon Sep 28 12:38:29 BST 2020 armv7l GNU/Linux


    64391b28301e92914ba35e345da6e11fab3afd6b => fail

    Linux RPI-VDR 5.4.68-v7+ #1343 SMP Mon Sep 28 12:38:29 BST 2020 armv7l GNU/Linux


    firmware: video_decode: Only shutdown codec on both ports being disabled

    firmware: vc_image_helper: Avoid misaligned exception due to uninitialised pointer

    firmware: arm_loader: Make arm clock accesses only see their own boosts

    See: raspberrypi/firmware#1469


    Kennt jemand eine Lösung des Problems?


    Gruß Zimuland

  • Hatten wir das Thema nicht schon mal ?


    Kann mich aber nicht an die Lösung erinnern.:)

  • Meine Lösung war mit rpi-update die letzte funktionierende Kernel-Version zu installieren. Ich hatte damals die Liste der Versionen Schritt für Schritt durchprobiert. Eine Lösung für die neueren Kernel-Versionen kenne ich bisher auch nicht.

    Code
    1. rpi-update 26620cc9a63c6cb9965374d509479b4ee2c30241
  • Meine Lösung war mit rpi-update die letzte funktionierende Kernel-Version zu installieren. Ich hatte damals die Liste der Versionen Schritt für Schritt durchprobiert. Eine Lösung für die neueren Kernel-Versionen kenne ich bisher auch nicht.

    Hallo,


    vielen dank, läuft wieder, damit hast du mir das zurücktesten gespart, kam von 4.19 und hatte die 5.4.79 und 5.10.2-v7 versucht damit ging es auch nicht.

    Mittlerweile sogar von vdr 2.4.1 auf vdr 2.4.4 geupdatet in der hoffnung das es hilft.


    Jetzt können wir nur hoffen das es irgendwann eine Lösung dafür gibt.

  • Ich habe dieses Problem auch, darum bleibe ich leider bei allen meinen Raspi's auf 4.19.

    Ich habe auch keine Ahnung wo das Problem liegt.

  • Das Problem macht wohl das rpihddevice. Es fehlen (nach Umschalten) auch Einträge zum Bildformat im Log.


    Denke durch "firmware: video_decode: Only shutdown codec on both ports being disabled" bekommt da irgendwas die Änderung nicht mit. Menü -> Restart und Bild ist da. Also fehlt vermutlich ein Codec-Reinit.


    (Als Hinweis an reufer )


    Grüße,

    Stefan


  • Had the same problem, while trying to get the mcli plugin working with 2.4.4 and thanks to Fourty2 's hint here is a rather
    heavy handed approach which just modifies the Clear() to completely reset things. Its certainly _not_ the real solution and likely

    leaking memory and other resources, its also quite slow, it is however now working for my 'Live Viewing' needs with kernel

    5.10.3-v7+ and the firmware:


    Code
    1.  $ /opt/vc/bin/vcgencmd version
    2.  Dec 15 2020 18:34:30
    3.  Copyright (c) 2012 Broadcom
    4.  version 4b4aff21f72c5b9ba39d83c7b0f8fa910a6ef99b (clean) (release) (start)

    So if you want to try building your own rpihddevice plugin....



    mfg


    Alan

  • Der Patch ist heute auch in die MLD 5.5 unstable für den RPi3 eingeflossen. Damit klappt bei mir das Umschalten zwischen HD-Sendern, wenn auch, wie bereits erwähnt, nur zeitverzögert. Ein Wechsel von einen HD-Sender auf einen SD-Sender führt bei mir zum Absturz des VDR (Segfault). Ein Abspielen von Aufnahmen war bei einem ersten Test nicht möglich. Wäre prima, wenn das Problem endgültig gefixt werden könnte.


    Viele Grüße skippy

  • Ich bin mit dem rpihddevice nicht vertraut, aber vor 15 Jahren habe ich mich bei der Entwicklung des pvr350-Plugins ausgiebig mit der Funktion von Ausgabedevices beschäftigt. Wenn Euer Problem nur beim Umschalten auftritt, dann ist Clear() m.E. nicht die richtige Stelle. Entscheidend ist SetPlayMode. In "case pmNone" steht der Code, der beim Stoppen des Dekoders ausgeführt wird. (Wenn danach wieder Pakete an das device geschickt werden, springt der Dekoder automatisch wieder an, deshalb steht für die anderen Fälle wie pmAudioVideo auch wenig drin.)


    Das meiste, was mit dem Patch jetzt in Clear() ausgeführt wird, findet bereit bei Playmode pmNone, also bei jedem Kanalwechsel statt.

    Neu ist nur

    Code
    1. DeInit();
    2. Init();
    3. SetVolumeDevice(CurrentVolume());

    Ich würde an Eurer Stelle jetzt mal versuchen, anstelle des Patches einfach SetPlaymode zu ergänzen , nämlich


    Möglicherweise findet in Init() und DeInit() auch zuviel unnötiges für einen Kanalwechsel statt. Was die Aufrufe von cRpiSetup::SetVideoSetupChangedCallback jeweils bewirken, überblicke ich nicht. Vielleicht reicht es, in obigem Vorschlag anstelle von DeInit() und Init() auch nur Teile deren Inhalts einzufügen.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Vielen Dank für deinen Tipp. Die Entwickler der MLD haben das Plugin in der MLD 5.5 unstable für den RPi3 entsprechend angepasst. Bei mir sind die genannten Probleme damit verschwunden. Umschalten auch von HD nach SD sowie umgekehrt, als auch das Abspielen von Aufnahmen funktioniert damit wieder wie gewohnt.


    Viele Grüße skippy

  • Vielen Dank für deinen Tipp. Die Entwickler der MLD haben das Plugin in der MLD 5.5 unstable für den RPi3 entsprechend angepasst. Bei mir sind die genannten Probleme damit verschwunden. Umschalten auch von HD nach SD sowie umgekehrt, als auch das Abspielen von Aufnahmen funktioniert damit wieder wie gewohnt.


    Könntet ihr hier nicht nochmal den finalen Patch posten für rpihddevice?

    Danke

  • Der Patch ist im git von MLD.


    Allerdings haben die den zusätzlich zur ersten Änderung in Clear() drin, von der ich nicht überzeugt bin.

    Wenn ich mich richtig erinnere, wird Clear bei der Wiedergabe benutzt, wenn man mit gelber oder grüner Taste Sprünge in Aufnahmen macht oder mit gedrückten Tasten spult. Evtl. auch beim langsamen oder schnellen Bildsuchlauf vor und rückwärts bzw. bei der Rückkehr zu normaler Wiedergabe. Und beim Setzen von Schnittmarken bzw. dem Springen von einer Schnittmarke zur anderen. Funktioniert das denn alles wie gewohnt?

    ACT-620, Asrock B75 Pro3-M, 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.

  • Hi,


    Nein wir haben die erste Änderung nicht drin.

    Nur die Änderung die sich auf den 'SetPlaymode' bezieht.


    Gruß,

    Roland


  • Das Log sagt aber etwas anderes. Ich vermisse da den revert des changes from 23.02.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Der Patch hat den gleichen Namen wie der erste, er ist einfach nur geändert worden.


  • o.k.


    Ist das Umschalten wirklich genauso schnell wie mit dem alten Kernel? Falls es immer noch einen Moment länger dauern sollte, könntet Ihr mal probieren, in SetPlayMode anstelle von Init();

    nur

    Code
    1. m_omx->Init(m_display, m_layer);
    2. m_audio->Init();

    und anstelle von DeInit();

    Code
    1. m_audio->DeInit();
    2. m_omx->DeInit();

    zu setzen.

    ACT-620, Asrock B75 Pro3-M, 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.