RPI 3B+: Kein Bild nach dem Umschalten

Hi,

Also Audio und Video einzeln neu initialisieren.

Wie kommst du auf die Idee?

Gruß,

Roland

das ist im Prinzip nichts anderes, als auch in Init() und DeInit() gemacht wird

int cOmxDevice::Init(void)
{
	if (m_omx->Init(m_display, m_layer) < 0)
	{
		ELOG("failed to initialize OMX!");
		return -1;
	}
	if (m_audio->Init() < 0)
	{
		ELOG("failed to initialize audio!");
		return -1;
	}
	m_omx->SetBufferStallCallback(&OnBufferStall, this);
	m_omx->SetEndOfStreamCallback(&OnEndOfStream, this);
	m_omx->SetStreamStartCallback(&OnStreamStart, this);

	cRpiSetup::SetVideoSetupChangedCallback(&OnVideoSetupChanged, this);

	return 0;
}

int cOmxDevice::DeInit(void)
{
	cRpiSetup::SetVideoSetupChangedCallback(0);
	if (m_audio->DeInit() < 0)
	{
		ELOG("failed to deinitialize audio!");
		return -1;
	}
	if (m_omx->DeInit() < 0)
	{
		ELOG("failed to deinitialize OMX!");
		return -1;
	}
	return 0;
}

Da findet noch mehr statt, aber vielleicht ist das gar nicht notwendig für einen simplen Kanalwechsel

Hi,

Ich habe jetzt den attachten Patch ausprobiert, geht bei mir ohne Probleme.

~ Markus

Bringt es beim Umschalten Geschwindigkeitsvorteile ggü. DeInit() und Init() an der gleichen Stelle in SetPlayMode?

Moin,

auf meinem RPI-3B läuft satip und iptv.

Ich habe den Kernel auf die neuste Version hochgezogen und den Patch angewendet.

Beim Umschalten auf einen IPTV-Sender schmiert der VDR ab ohne Log-Message.

Scheint noch nicht so ganz das Wahre zu sein.

Quote from mamomoz

Moin,

auf meinem RPI-3B läuft satip und iptv.

Ich habe den Kernel auf die neuste Version hochgezogen und den Patch angewendet.

Beim Umschalten auf einen IPTV-Sender schmiert der VDR ab ohne Log-Message.

Scheint noch nicht so ganz das Wahre zu sein.

Und was ist bei satip Sendern ?

Hallo,

das Umschalten bei satip-Sendern klappt.

Quote from mamomoz

Hallo,

das Umschalten bei satip-Sendern klappt.

Dann würde ich sagen, das eher das IPTV Plugin abschmiert.

Also sieht das neu so aus:

bool cOmxDevice::SetPlayMode(ePlayMode PlayMode)
{
    m_mutex->Lock();
    DBG("SetPlayMode(%s)",
        PlayMode == pmNone             ? "none"                :
        PlayMode == pmAudioVideo     ? "Audio/Video"        :
        PlayMode == pmAudioOnly         ? "Audio only"        :
        PlayMode == pmAudioOnlyBlack ? "Audio only, black" :
        PlayMode == pmVideoOnly         ? "Video only"        : 
                                       "unsupported");

    // Stop audio / video if play mode is set to pmNone. Start
    // is triggered once a packet is going to be played, since
    // we don't know what kind of stream we'll get (audio-only,
    // video-only or both) after SetPlayMode() - VDR will always
    // pass pmAudioVideo as argument.

    switch (PlayMode)
    {
    case pmNone:
        if( m_playMode != pmNone )
        {
            FlushStreams(true);
            m_omx->StopVideo();
            m_hasAudio = false;
            m_hasVideo = false;
            m_videoCodec = cVideoCodec::eInvalid;
            m_audio->DeInit();
            m_omx->DeInit();
            m_playMode = pmNone;
        }
        break;

    case pmAudioVideo:
    case pmAudioOnly:
    case pmAudioOnlyBlack:
    case pmVideoOnly:
        m_omx->Init(m_display, m_layer);
        m_audio->Init();
        SetVolumeDevice(CurrentVolume());
        m_playbackSpeed = eNormal;
        m_direction = eForward;
        break;

    default:
        break;
    }

    m_mutex->Unlock();
    return true;
}

Quote

Beim Start des Plugins wird SetPlayMode() zurerst mit 0 (pmNone)

... dabei wird auch m_playmode auf pmNone gesetzt

Quote

und danach mit 5 (pmExtern_THIS_SHOULD_BE_AVOIDED) aufgerufen.

ich finde keine Stelle im Plugin, wo dabei auch m_playmode auf 5 gesetzt wird!

Quote

Beim Beenden des Plugins folgt dann wieder ein Aufruf mit 0 (pmNone).

Dass Deine Änderung ein erneutes Ausführen des Codes in pmNone verhindert, liegt nur daran, dass m_playmode zu diesem Zeitpunkt immer noch 0 und nicht 5 ist, was m.E. ein Bug im Code ist: Das m_playMode = pmNone; gehört m.E. ans Ende vor return true;, damit alle Playmode-Änderungen erfasst werden. Warum reufer das nur für den case pmNone vorgesehen hatte - keine Ahnung.

Das TV-Bild kommt nach dem Beenden des mplayer-Plugins trotzdem normal zurückt? Das ist interessant: Nach einem Kanalwechsel im Plugin selbst will die Hardware neu initialisiert werden, aber nach Verwendung des externen omxplayers ist das nicht nötig!

Im rpihddevice-Plugin ist derzeit überhaupt keine Handhabung für den Playmode pmExtern_THIS_SHOULD_BE_AVOIDED implementiert. Da der externe omxplayer bei laufendem Plugin funktioniert, hat das rpihddevice-Plugin anscheinend keinen exklusiven Zugriff auf die Hardware. Der omxplayer kann nun aber Initialisierungen an der Hardware durchführen, die das Plugin gar nicht mitkriegt. Deshalb wäre es schon besser, wenn das Plugin nach Rückkehr vom omxplayer re-initialisiert würde.

Zu Deinem Problem: Die clock wird in m_omx->DeInit() zerstört und erst in m_omx->Init() wieder erzeugt. Nach dem ersten pmNone (vor dem Aufruf des mplayer-Plugins) ist die clock also schon weg. Wenn dann nach Rückkehr vom mplayer-Plugin erneut pmNone aufgerufen wird und über FlushStreams m_omx->StopClock(); und m_omx->ResetClock();aufgerufen werden, crasht es.

Probier doch mal folgendes:

bool cOmxDevice::SetPlayMode(ePlayMode PlayMode)
{
    m_mutex->Lock();
    DBG("SetPlayMode(%s)",
        PlayMode == pmNone             ? "none"                :
        PlayMode == pmAudioVideo     ? "Audio/Video"        :
        PlayMode == pmAudioOnly         ? "Audio only"        :
        PlayMode == pmAudioOnlyBlack ? "Audio only, black" :
        PlayMode == pmVideoOnly         ? "Video only"        : 
                                       "unsupported");

    // Stop audio / video if play mode is set to pmNone. Start
    // is triggered once a packet is going to be played, since
    // we don't know what kind of stream we'll get (audio-only,
    // video-only or both) after SetPlayMode() - VDR will always
    // pass pmAudioVideo as argument.

    switch (PlayMode)
    {
    case pmNone:
        FlushStreams(true);
        m_omx->StopVideo();
        m_hasAudio = false;
        m_hasVideo = false;
        m_videoCodec = cVideoCodec::eInvalid;
        m_audio->DeInit();
        m_omx->DeInit();
        m_omx->Init(m_display, m_layer);    
        m_audio->Init();    
        break;

    case pmAudioVideo:
    case pmAudioOnly:
    case pmAudioOnlyBlack:
    case pmVideoOnly:
        m_playbackSpeed = eNormal;
        m_direction = eForward;
        break;

    default:
        break;
    }

    m_mutex->Unlock();
    m_playMode = PlayMode;
    return true;
}

Das Resetten findet hier also komplett in pmNone statt und damit auch bei jedem Kanalwechsel. Keine Ahnung, ob das Umschaltproblem damit auch gelöst ist und ob es Einfluss auf die Umschaltdauer hat. ich habe hier übrigens SetVolumeDevice(CurrentVolume()); rausgelassen, denn der Sinn im ursprünglichen Patch erschließt sich mir nicht. Es würde ja dazu führen, dass ein vorher stumm gemuteter vdr beim Kanalwechsel wieder laut wird.

Bitte testen!

Hallo,

ich habe den letzten Patch getestet. Er behebt das Problem beim Umschalten. Die Umschaltdauer bleibt leider gleich. Das Zappen von Kanal 1 bis 10 dauert ca. 27 Sekunden.

Danke

Motz_e

Frage an alle: Ist die Umschaltgeschwindigkeit mit einer der letzten Änderungsvarianten denn wieder auf dem Niveau wie vor der Kerneländerung, oder immer noch etwas langsamer?

Ich habe gestern mit dem aktuellen Raspian OS vdr + rpihddevice selbst kompiliert und mit dem iptv-Plugin auf meinem Raspi 2 ausprobiert. Es reicht anscheinend, nur m_omx zu deinitialisieren und neu zu initialisieren. Für m_audio ist es scheinbar nicht notwendig. Aber ich habe stets eine Umschaltgeschwindigkeit von über 2 Sekunden, meist sind es 3 oder 4. Kann aber auch an MagentaTV und dem langsamen LAN des Raspi 2 liegen. Mit einem Hauppauge DVB-C-USB Stick kriege ich keinen Empfang, liegt vielleicht daran, dass im Log was von Undervolting steht. Muss ich mit einem aktiven USB Hub nochmal probieren.

zimuland: so führst Du SetVolumeDevice aber bei JEDEM Kanalwechsel durch, solange der Ton nicht gemutet ist. Ich würde da jede unnötige Aktion vermeiden. Es müsste möglich sein, das nur auszuführen, wenn der letzte Playmode zuvor 5 war.

Quote from rfehr

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

Stehe gerade vor dem gleichen Problem nachdem ich mein Pi endlich mal aktualisiert habe.

Dumme Frage: Wo finde ich das aktuelle Paket? Unter GIT sind nur alte.

Im Voraus vielen Dank!

Hi,

Der Endstand fehlt hier im Thema aber irgendwie, oder?

MfG Stefan

Hi,

hier: https://github.com/vdr-projects/vdr-plugin-rpihddevice ist der Endstand.

Falls es damit noch Probleme gibt, bitte melden.

~ Markus

Läuft hier seit ca. 2 Stunden auf drei RPI3+, wirklich super.

Danke für deine Mühe Markus.

Freut mich zu hören

Hallo Alle, ich habe seit einiger Zeit dieses Problem mit der MLD-5.5.

Ich habe einen RPI3 mit MLD5.4. Da funktioniert alles.

Bei den zwei anderen RPI3 mit MLD5.5 tritt das Problem auf:

Normaler Start, Fernsehbild (vom Server yavdr) wird angezeigt, nach Umschalten zeigt sich kein Bild.

Gab es irgendeine Änderung am rpihddevice?

Ich habe die neueste Version von MLD5.5 installiert.