RPI 3B+: Kein Bild nach dem Umschalten

Hatten wir das Thema nicht schon mal ?

Kann mich aber nicht an die Lösung erinnern.

Hallo,

gab es eine lösung zu dem problem, bin beim updaten genau auf das selbe verhalten gestoßen...

mfg bacardi

Quote from zimuland

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

Quote from bacardischmal

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.

Display More

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:

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

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

diff --git a/omxdevice.c b/omxdevice.c
index c646f90..4288373 100644
--- a/omxdevice.c
+++ b/omxdevice.c
@@ -532,9 +532,23 @@ void cOmxDevice::Clear(void)
DBG("Clear()");
m_mutex->Lock();

+#if 0
FlushStreams();
m_hasAudio = false;
m_hasVideo = false;
+#else
+       FlushStreams(true);
+       m_omx->StopVideo();
+       m_hasAudio = false;
+       m_hasVideo = false;
+       m_videoCodec = cVideoCodec::eInvalid;
+       m_playMode = pmNone;
+
+       DeInit();
+       Init();
+
+       SetVolumeDevice(CurrentVolume());
+#endif

m_mutex->Unlock();
cDevice::Clear();

mfg

Alan

reufer ... zur Info.

Thanks Alan for the patch.

I can confirme, it works.

Negative side effect is, it needs any seconds to lock the video now.

My setup:

vdr-2.4.6, rpihddevice-1.0.5 ( with your Patch)

kernel 5.4.79-v7+

iam still using the old rpi-userland from 20160424.

Thanks Jörg

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

DeInit();
Init();
SetVolumeDevice(CurrentVolume());

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

case pmNone:
        FlushStreams(true);
        m_omx->StopVideo();
        m_hasAudio = false;
        m_hasVideo = false;
        m_videoCodec = cVideoCodec::eInvalid;
        DeInit();
        m_playMode = pmNone;
        break;

    case pmAudioVideo:
    case pmAudioOnly:
    case pmAudioOnlyBlack:
    case pmVideoOnly:
        Init();
        SetVolumeDevice(CurrentVolume());
        m_playbackSpeed = eNormal;
        m_direction = eForward;
        break;

    default:
        break;

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.

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

Quote from 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?

Hi,

Nein wir haben die erste Änderung nicht drin.

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

Gruß,

Roland

Quote from rfehr

Hi,

Nein wir haben die erste Änderung nicht drin.

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

Gruß,

Roland

Display More

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

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

m_omx->Init(m_display, m_layer);
m_audio->Init();

und anstelle von DeInit();

m_audio->DeInit();
m_omx->DeInit();

zu setzen.