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

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.

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:

bool cPatFilter::PmtVersionChanged(int PmtPid, int Sid, int Version, bool SetNewVersion)
{
  int i = 0;
  for (cPmtSidEntry *se = pmtSidList.First(); se; se = pmtSidList.Next(se), i++) {
      if (se->Sid() == Sid && se->Pid() == PmtPid) {
         if (!se->Received()) {
            se->SetReceived(true);
            if (PmtPidComplete(PmtPid))
               se->PidEntry()->SetComplete(true);
            }
         if (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;
            }
         break;
         }
      }
  return false;
}

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

LG Helmut

Ich werde diese PmtVersionChanged() am Abend in den "vdr-2.4.5-pat-fix-channels-lock-fail-01.diff" von Klaus integrieren.

LG Helmut

Quote from jrie

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.

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

Ja, das ist auch mein Letztstand.

LG Helmut

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

kamel5 - Ich habe das aktualiesierte git erst jetzt bemerkt und es sind bereits alle letztgültigen Patches aus diesem Thread enthalten.

LG Helmut