[Patch] Fehler bei Timeraufnahmen durch Lock der "Channels" in cRecordControls::Start()

  • Und entwirren könnte man es vielleicht so

    Das hat mich jetzt ehrlich gesagt eher etwas *ver*wirrt ;-), weil es wohl nichts gegen einen eventuell unnötigen Lock auf die Channels unternimmt.


    Wie wäre es denn mit beiliegender Version?

    Enthält vdr-2.4.4-pat-fix-shared-pmt.diff sowie die Änderung von hier.

    Entscheidend sind die letzten beiden Hunks. Zunächst wird PmtVersionChanged(... false) aufgerufen, womit lediglich eine Änderung der Version geprüft wird. Hat sich diese geändert, werden die Channels gelockt und PmtVersionChanged(... true) gemacht.


    HelmutB Meinst du, dass das so stimmen kann?


    Fourty2 Kannst du es bitte hiermit testen?

  • Damit 'activePmt->Complete()' irgendwann 'true' wird, muss die aktuelle SID als 'Received' makiert werden - auch wenn sich die PMT-Version nicht geändert hat - sonst werden ab dem zweitem Umlauf die PMT-Pids nicht mehr gewechselt.

    Ich habe deshalb in deinem Patch im 3.Hunk noch eine Zeile mit 'PmtVersionChanged()' und SetNewVersion=true eingefügt.

    Bei mir gibt es damit keine Auffälligkeiten, aber der Massstab ist hier eher Fourty2 mit den vielen Timern und Plugins.


    Die "Entwirrung" hat sich nur auf die sich wiederholenden 3 Zeilen vor SwitchToNextPmtPid()' bezogen und diese etwas zusammengefasst.
    LG Helmut


    PS. mit meinem vdr-2-4-4-recordcontrolsstart-early-channels-unlock-patch stimmt irgend etwas nicht, Ich bekomme damit eine 'invalid lock sequence 2 Channels', dem muss ich noch nachgehen.

  • Patchstand (quilt series):

    #vdr-2.4.5-pat-lock-channels-early.diff
    vdr-2.4.5-pat-fix-channels-lock-fail-01A.diff
    ##vdr-2.4.4-pat-log-GetChannelsWrite.patch
    #vdr-2.4.4-pat-fix-shared-pmt.diff
    ##vdr-2.4.4-pat-lock-channels-resetSid.diff


    Läuft bisher wie mit dem ersten Klaus'schen diff.


    Weitere Tests dann, wenn ich der elterlichen Heizung das F28 abgewöhnt habe


    Stefan

  • Mir ist jetzt noch mehr klar geworden. Die "robuste" Lösung für GetChanneslWrite() die Klaus hier eingebaut hat, hat es bis VDR-2.4.2 immer schon gegeben. Sie ist aber mit meinem Patch für die "shared PMTPds" leider rausgefallen.


    Die von mir eingefügte Zeile im "vdr-2.4.5-pat-fix-channels-lock-fail-01A.diff" kann entfallen, wenn Received() im PmtVersionChanged() immer gesetzt wird, so wie hier:

    Damit wäre der Ablauf in Process() wieder so wie in VDR-2.4.2.

    LG Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Die "robuste" Lösung für GetChanneslWrite() die Klaus hier eingebaut hat, hat es bis VDR-2.4.2 immer schon gegeben. Sie ist aber mit meinem Patch für die "shared PMTPds" leider rausgefallen.

    Das würde meine Beobachtung hier erklären.

  • Das würde meine Beobachtung hier erklären.

    Genau, ein Update auf vdr-2.4.3 oder neuer.


    Hier nun der Patch mit adaptiertem 'PmtVersionChanged()' im 1.Hunk, der Rest ist so wie im 'vdr-2.4.5-pat-fix-channels-lock-fail-01.diff' von Klaus. Es sollte sich jetzt wieder alles so Verhalten wie mit vdr-2.4.2.

    Fourty2 - kannst du das Bitte auch noch testen.

  • Gerade noch schnell eingebaut, Start mit zwei Aufnahmen, VDSB. Hmm.

    ==> /var/log/vdr.log <==

    Dec 11 10:23:10 roadrunner vdr: scraper2vdr: epgd busy, trying again in 60 seconds ...

    Dec 11 10:23:14 roadrunner vdr: [7371] ERROR: video data stream broken

    Dec 11 10:23:14 roadrunner vdr: [7371] emergency exit request ignored according to setup

    Dec 11 10:23:16 roadrunner vdr: [7357] VAAPI-ERROR: video/vaapi: black surface displayed

    Dec 11 10:23:16 roadrunner vdr: [7357] VAAPI: video: --:--:--.--- +0 0 0/\ms 0+0 v-buf


    Beim zweiten Start ging es aber. Untersuche das später/am WE noch genauer, da gestern auch der per Streamdev angeschlossene RPI nur für das Startprogramm Bild zeigte, nach Umschalten oder bei Abspielversuch Bild weg ... hab' dann erstmal mit was anderem spielen "müssen"... :)


    Stefan

  • Hier nun der Patch mit adaptiertem 'PmtVersionChanged()' im 1.Hunk

    So ganz verstehe ich das jetzt nicht:

    Code
              if (se->Version() != Version) {
    -            DBGLOG("PMT %d  %2d %5d/%d %2d -> %2d", Transponder(), i, PmtPid, Sid, se->Version(), Version);
                 if (SetNewVersion)
                    se->SetVersion(Version);
    +            else
    +               DBGLOG("PMT %d  %2d %5d/%d %2d -> %2d", Transponder(), i, PmtPid, Sid, se->Version(), Version);
                 return true;
                 }

    Damit hast du doch nur die Debug-Ausgabe verlagert. Funktionell ändert das doch nichts!?

    Die Änderung von mir, durch die PmtVersionChanged(..., false) als Query-Funktion verwendet werden kann, hast du wieder ausgebaut. Die Funktion arbeitet damit genau wie vor meiner Änderung, es kann also nicht richtig funktionieren.

    Oder übersehe ich da was?

  • Naja, das Ganze beruht bei menem "shared PMT-Pid" Patch auf dem Missverständnis, dass ich in 'cPatFilter::Process()' schon beim ersten Aufruf von 'PmtVersionChanged()' schon 'SetNewVersion = true' mitgegeben habe ohne zu erkennen, dass damit bei einem Fehler beim darauffolgenden 'GetChannelsWrite()' diese und alle folgenden PMTs mit gleicher Version für diese Service-ID nicht mehr ausgewertet werden.

    Zusätzlich habe ich damals das zweite 'PmtVersionChanged()', weil für mich nun unötig, auch gelöscht und, damit die Debugmeldungen wieder aufscheinen, diese aus der if/else Abfrage herausgeholt.

    Funktionell war PmtVersionChange() dadurch nicht falsch, sie wurde aber nicht mehr für ein "query" verwendet.


    Du hast mit den beiden 'PmtVersionChanged()' Aufrufen meine Fehler wieder richtiggestellt, und ich habe die Debug-Ausgabe wieder in ein 'else' verschoben damit sie nur einmal aufscheint.

    Das ganze läuft jetzt wieder so wie in vdr-2.4.2.


    Neu zu vdr-2.4.2 ist der Wechsel auf die nächste PMT-Pid. Dieser Wechsel erfolgt erst, wenn die PMTs für alle SIDs der aktiven PMT-Pid gesehen wurden. 'activePmt->Complete()'' gibt dann "true" zurück.

    Das wird in PmtVersionChanged() im 'if (!se->Received())' Block. gesteuert, und dieser Abschnitt muss immer ausgeführt werden, sonst bleibt man bei der zweiten Wiederholung ziemlich sicher auf einer PMT-Pid hängen . Daher war mein Vorschlag aus Post #21 auch nicht sinnvoll und ich habe ihn wieder entfernt.


    Doch etwas verwirrend - ich geb's zu.

    LG Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • So, der rpi2 auf obigem Patchlevel läuft wieder.


    Die rpi-update Firmware ist (zumindest) ab 5.4.79 nicht mit rpihddevice nutzbar.
    Mit 5.4.51 gehts wieder. Dann arbeiten wir uns mal Firmwaretechnisch vor, bevor wir den Haupt-VDR anfassen...


    Stefan

  • Ich benutze da folgenden script


  • Durch die frühe Freigabe des "großen" Channels-Lock in cRecordControls::Start() im Patch des 1. Post hatte ich immer eine "invalid lock sequence" bei einer Instant-Aufnahme (<Menü><rote Taste>).

    Der Grund war, dass in cRecordControl() die Schedules gelockt werden, was aber dann in cTimer() beim Versuch einen Lock auf die - beim Locking niederwertigen - Channels zu bekommen diese Fehlermeldung erzeugt.

    Zur Korrektur wird nun vor dem Erstellen eines neuen Timers in cRecordControl() vor dem Lock auf Schedules ein kurzer Pre-Lock auf die Channels erzeugt. Damit stimmt die "locking sequence" wieder.

    Helmut

  • Hallo HelmutB ,


    nachdem kls sein git aktualisiert hat, habe ich etwas den Überblick verloren.

    Ist von den Patches hier im thread zusätzlich noch was nötig oder sind die dann obsolet?


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

Jetzt mitmachen!

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