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

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

    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.

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

    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.

  • 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.

  • 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.

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

  • Hallo,

    bei der Verwendung des mplayer-Plugins (mit omxplayer-patch) gibt es auch das Problem, dass beim Beenden des Plugins der VDR neu startet.


    Beim Start des Plugins wird SetPlayMode() zurerst mit 0 (pmNone) und danach mit 5 (pmExtern_THIS_SHOULD_BE_AVOIDED) aufgerufen.

    Beim Beenden des Plugins folgt dann wieder ein Aufruf mit 0 (pmNone). Dabei kommt es beim Aufruf von FlushBuffers() zum Absturzin in SetClock() bzw. ResetClock() aufgrund eines Null-Pointers.


    Dieser modifizierte Patch hat das Problem für mich gelöst: rpihddevice-fix_playmode_zimuland.patch


    Gruß Zimuland

  • Also sieht das neu so aus:

    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:


    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!

    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.

  • 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

    VDR-Clients:
    Raspbian Jessie mit Paketen von eTobi - vdr 2.2 - Raspberry PI 1B
    Raspbian Buster
    mit Paketen von eTobi - vdr 2.4 - Raspberry PI 2B


    Home-Server:
    Debian Bullseye - vdr 2.4.1 - Kernel 5.10.0-3

    Asus Prime B360M-C - Pentium Gold G5400 - Mystique SaTiX-S2 Dual - Hauppauge WinTV-QuadHD

    The post was edited 1 time, last by motze ().

  • Vielen Dank für Deine ausführliche Analyse. Deine Version des Patches löst das Problem im Endeffekt ebenfalls.

    Das Setzen vom m_playMode hätte ich aber noch in den Lock() verschoben.


    Code
    1.     m_playMode = PlayMode;
    2. m_mutex->Unlock();
    3.     return true;
    4. }



    Quote

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

    Das SetPlayMode() wird direkt vom VDR aufgerufen und kommt wahrscheinlich von dieser Zeile im mplayer-Plugin:

    Code
    1. cMPlayerPlayer::cMPlayerPlayer(const cFileObj *File, bool Rewind)
    2. :cPlayer(pmExtern_THIS_SHOULD_BE_AVOIDED)
    3. {


    Quote

    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.

    Die Initialisierung findet ja trotzdem statt. Nach dem Beenden des Plugins wird wieder zuerst pmNone und danach pmAudioVideo gesendet.


    Quote

    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.

    Das war mir bisher noch gar nicht aufgefallen, ist aber tatsächlich so.

    Der Ton scheint aber nach der Reinitialisierung immer an zu sein. Damit sorgt der Aufruf im Endeffekt nur dafür, dass die im VDR eingestellte Lautstärke verwendet wird. Damt sollte die folgende Variante korrekt sein, damit das Mute auch beibehalten wird:

    Code
    1. SetVolumeDevice( IsMute() ? 0 : CurrentVolume() );


    Quote

    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.

    Das führt im Fall von pmExtern_THIS_SHOULD_BE_AVOIDED im Endeffekt dazu, dass eine Initialisierung durchgeführt wird, die am Ende nicht gebraucht wird.


    Das pmExtern_THIS_SHOULD_BE_AVOIDED im Plugin nicht behandelt wird ist meiner Meinung nach so gewollt, da ja der externe Player alle Arbeit übernimmt. Die Variable m_playMode bleibt auf pmNone, bis sie in PlayAudio() oder PlayVideo() auf den entsprechenden Mode gesetzt wird. Wurde keine dieser Funktionen aufgerufen ist wahrscheinlich auch kein FlushStreams() notwendig.

  • 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.

    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.

  • Das SetVolumeDevice() kam ja ursprünglich schon durch den Patch von MarkusE rein. Ich habe in meiner Variante jetzt nur noch die Unterscheidung mit IsMute() ergänzt. Ohne das SetVolumeDevice() wird die Lautstärke bei mir aber jedem Kanalwechsel auf einen Default-Wert gesetzt, nicht nur wenn man einen externen Player nutzt. Mir war das auch nur aufgefallen, weil ich den Ton beim letzten Test ziemlich leise eingestellt hatte.
    Die Umschaltzeiten liegen mit SetVolumeDevice() bei HD-Sendern auf dem gleichen Transponder bei etwa zwei Sekunden und bei unterschiedlichen Transpondern bei reichlich drei Sekunden. Getestet habe ich mit einen Terratec Cinergy HTC Stick mit DVB-C mit einem Raspi 3.

  • 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!