[epgsearch] Suchtimer erzeugt nicht alle passenden Timer

    Hi Klaus,


    Ich lese

    Code
    int overlap = 0;
if (Matches(e, &overlap) == tmFull) {
  Event = e;
  if (overlap > FULLMATCH)
    break; // take the first matching event
}

    so:


    Falls für das erste Event mit der korrekten VPS Zeit (overlap > FULLMATCH) ist, wird dieses erste Event zugeordnet. Andernfalls nicht.

    D.h. , falls für das erste Event mit der korrekten VPS Zeit (overlap <= FULLMATCH) ist, wird dieses erste Event nur zufällig aufgezeichnet, oder auch nicht.


    Falls es kein Event mit der korrekten VPS Zeit gibt, für das (overlap > FULLMATCH) ist, wird das letzte Event zugeordnet. Leuchtet mir nicht ein.

    Wird die Prüfung (overlap > FULLMATCH) benötigt oder nicht? Falls sie benötigt wird, warum steht dann nicht


    Code
    int overlap = 0;
if (Matches(e, &overlap) == tmFull && overlap > FULLMATCH) {
  Event = e;
  break; // take the first matching event
}

    ?



    Zu

    Code
    eTimerMatch cTimer::Matches(const cEvent *Event, int *Overlap) const


    Hier stimmt die Dokumentation nicht mit der Implementierung überein.

    Code
    // To make sure a VPS timer can be distinguished from a plain 100% overlap,
// it gets an additional 100 added

    Das stimmt aber nur, falls (Event->RunningStatus() != SI::RunningStatusNotRunning) ist.


    Ich würde mal sagen, bei mir war "Event->RunningStatus() == SI::RunningStatusNotRunning", als ich den Timer angelegt habe. Und bei Dir nicht. Warum auch immer ...



    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    MarkusE

    SI::RunningStatusNotRunning bedeutet, dass der Event bereits abgelaufen ist. Ein bereits abgelaufener VPS-Event darf natürlich nicht mehr berücksichtigt werden. Warum der bei dir auf SI::RunningStatusNotRunning gestanden haben sollte , als du den Timer angelegt hast, weiß ich nicht. Dieser Status wird nur über die EIT-Daten gesetzt, und das auch nur am ENDE des Events.

    Quote from MarkusE

    Falls es kein Event mit der korrekten VPS Zeit gibt, für das (overlap > FULLMATCH) ist, wird das letzte Event zugeordnet.

    Ein Event mit korrekter VPS-Zeit und overlap == FULLMATCH ist ein VPS-Event, der weder aktuell läuft, noch in der Zukunft liegt, also ein vergangener Event. Ist overlap == FULLMATCH + 200, dann läuft er aktuell. Ist overlap == FULLMATCH + 100, dann liegt er in der Zukunft.

    Wenn also bei der Suche nach einem passenden VPS-Event einer gefunden wird, der overlap > FULLMATCH hat, dann läuft der entweder aktuell, oder liegt in der Zukunft, und die Suche kann beendet werden (die Events sind ja nach der Startzeit sortiert).

    Quote from MarkusE

    if (Matches(e, &overlap) == tmFull && overlap > FULLMATCH) {

    Auf den ersten Blick könnte man das vielleicht so machen, aber das würde ich nur ändern, wenn ich einen reproduzierbaren Fehlerfall hätte, der dadurch gefixt wird.

    Quote from MarkusE

    Das stimmt aber nur, falls (Event->RunningStatus() != SI::RunningStatusNotRunning) ist.

    Ein Event mit SI::RunningStatusNotRunning) ist ein "vergangener" Event, der keine Rolle mehr spielt.

    > Ein Event mit SI::RunningStatusNotRunning) ist ein "vergangener" Event, der keine Rolle mehr spielt.

    Das stimmt wohl nicht immer. In meinem Syslog finde ich z.B:

    Code
    2024-09-08T00:30:33.459700+02:00 rpi4s vdr: [940078] channel 2 (ZDF HD) event So. 08.09.2024 00:30-00:35 (VPS: 08.09. 00:30) 'heute Xpress' status 1->2

    d.h. der running Staus war vor Beginn des Events um 0:30 1 == RunningStatusNotRunning .

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Wenn ich void cSchedule::Sort(void) richtig lese, setzt diese Methode den Running status von allen Events vor dem gerade laufenden Event auf SI::RunningStatusNotRunning .


    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    MarkusE

    Quote from kls

    Dieser Status wird nur über die EIT-Daten gesetzt, und das auch nur am ENDE des Events.

    Ja, da muss ich mich wohl korrigieren - ist ja doch schon länger her... ;-).

    Quote from MarkusE

    Wenn ich void cSchedule::Sort(void) richtig lese, setzt diese Methode den Running status von allen Events vor dem gerade laufenden Event auf SI::RunningStatusNotRunning .

    Jetzt erinnere ich mich wieder. Das war notwendig, um abgelaufene Events sicher erkennen zu können.

    Siehe dazu auch eit.c:

    Quote from MarkusE

    d.h. der running Staus war vor Beginn des Events um 0:30 1 == RunningStatusNotRunning .

    Dazu müsste es aber nach diesem Event einen gegeben haben, der >= SI::RunningStatusPausing hatte. Kannst du mal die Log-Ausgaben dieses Kanals bzgl. Event-Status der Zeit vor 00:30:33 posten?

    Quote from kls

    Dazu müsste es aber nach diesem Event einen gegeben haben, der >= SI::RunningStatusPausing hatte. Kannst du mal die Log-Ausgaben dieses Kanals bzgl. Event-Status der Zeit vor 00:30:33 posten?


    Ja, hier:

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    MarkusE

    Auffällig ist, dass es bei dir keinen einzigen Übergang 0->X gibt. Bei mir gibt es dagegen keinen einzigen 1->X.

    Konkretes Beispiel (eines von vielen):

    Bei dir:

    Code
    2024-09-07T19:21:57.697474+02:00 rpi4s vdr: [940076] channel 2 (ZDF HD) event Sa. 07.09.2024 19:25-20:15 (VPS: 07.09. 19:25) 'Der Bergdoktor' status 1->2

    Bei mir:

    Code
    Sep  7 19:23:32 vdr4 vdr: [23386] channel 6 (ZDF HD) event Sat 07.09.2024 19:25-20:15 (VPS: 07.09. 19:25) 'Der Bergdoktor' status 0->2

    Jetzt wäre es wichtig, herauszufinden, warum bei dir alle Events auf '1' stehen, wenn sie auf '0' sein sollten.

    Hi Klaus,


    Ich habe mal zusätzliche Ausgaben eingebaut, so dass ich für jede Statusänderung einen Eintrag im syslog erhalte. Ich habe dann z.B. bekommen:


    Der Kanal fehlt, da dem System nicht bekannt. Ich denke, es ist Bayern 1. Alle Events erhalten den Status 1 == RunningStatusNotRunning.

    Vermutlich gibt es zu diesem Zeitpunkt kein Event mit (p->RunningStatus() >= SI::RunningStatusPausing).


    Hier der Code, mit dem ich die Zusätzlichen Ausgaben erzeugt habe:

    Code
    void cEvent::SetRunningStatus(int RunningStatus, const cChannel *Channel)
{
  if (runningStatus != RunningStatus) {
     if (Channel)
       isyslog("channel %d (%s) event %s status %d->%d", Channel->Number(), Channel->Name(), *ToDescr(), runningStatus, RunningStatus);
     else
       isyslog("                event %s status %d->%d",                                     *ToDescr(), runningStatus, RunningStatus);
  }
  runningStatus = RunningStatus;
}

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Quote from MarkusE

    Vermutlich gibt es zu diesem Zeitpunkt kein Event mit (p->RunningStatus() >= SI::RunningStatusPausing).

    Es wird aber in cSchedule::SetRunningStatus() explizit danach gesucht, und "hasRunning" nur dann auf true gesetzt, wenn es einen solchen Event gibt. Und in cSchedule::Sort() wird das abgefragt.


    Sind da irgendwelche Plugins im Spiel?

    Wenn ja, passiert es auch ohne diese?

    • New

    Hallo Klaus,


    Ich habe jetzt ohne Plugins getestet, und z.B. gefunden:


    Und viele mehr.



    > Es wird aber in cSchedule::SetRunningStatus() explizit danach gesucht, und "hasRunning" nur dann auf true gesetzt, wenn es einen solchen Event gibt. Und in cSchedule::Sort() wird das abgefragt.


    Und wie stellst Du sicher, dass die Information "hasRunning" zum Zeitpunkt, wenn cSchedule::Sort() aufgerufen wird, noch gültig ist? Da könnte in der Zwischenzeit z.B. das Event mit Running Status RunningStatusRunning gelöscht worden sein.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    • New

    > Es stellt sich aber schon die Frage, warum das bei dir ständig passiert und bei mir nie.

    Bist Du sicher, dass Du keine Events in der Zukunft mit Status 1 hast? Hast Du das bei Dir getestet? Ein ungepatchter VDR gibt diese Information ja nicht aus.


    Ich verwende DVB-S2, Serverbetrieb ohne Aufgabeplugin, "EPG pause after scan" ist ein, und es passiert auf verschiedenen Kanälen (HD, SD, Deutsch, Englisch (Astra2), ...)


    Und es passiert nicht beim ersten EIT Scan nach dem VDR Restart, sondern erst später, bei einem der folgenden Scans.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    • New
    Quote from MarkusE

    Bist Du sicher, dass Du keine Events in der Zukunft mit Status 1 hast?

    In all meinen Logfiles bis zurück zu Anfang November letzten Jahres kommt kein einziger Fall mit "0->1" vor.

    Quote from MarkusE

    Und es passiert nicht beim ersten EIT Scan nach dem VDR Restart, sondern erst später, bei einem der folgenden Scans.

    Das könnte eine heisse Spur sein, denn ich verwende "EPG pause after scan" nicht.

    Kannst du bitte mal verifizieren, ob es ohne das bei dir auch auftritt?

    Wenn es das nicht tut, dann schalte ich das hier auch mal ein und kann debuggen.

    • New

    > In all meinen Logfiles bis zurück zu Anfang November letzten Jahres kommt kein einziger Fall mit "0->1" vor.

    Klar.

    Code
    if (Channel && runningStatus != RunningStatus && (RunningStatus > SI::RunningStatusNotRunning || runningStatus > SI::RunningStatusUndefined) && schedule && schedule->HasTimer())
    isyslog("channel %d (%s) event %s status %d->%d", Channel->Number(), Channel->Name(), *ToDescr(), runningStatus, RunningStatus);

    verhindert, dass "0->1" im syslog auftaucht.

    Könntest Du bei Dir mal

    einbauen, und erneut testen?

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    • New

    Ich hatte das jetzt seit ca. 12 Stunden am Laufen mit

    und "EPG pause after scan" eingeschaltet ("EPG scan timeout" ist 1 Stunde). In der ganzen Zeit trat das von dir beobachtete Verhalten hier nicht auf.

    Welchen Wert hat denn bei dir "EPG linger time"? Ich hatte das auf 180 Minuten. Hab's jetzt testweise mal auf 5 Minuten runtergesetzt, mal sehen, ob das was ändert.

    • New

    Hab jetzt auch EPGlinger = 0 gesetzt, aber auch damit kein Fehler:

    Die Zeile mit "NO CHANNEL" trat kurz nach dem Ändern von EPGlinger auf, ist aber korrekt.

    Bei dir kommen ja alle Fehler aus der cSchedule::Sort(), weil das der einzige Aufruf von cEvent::SetRunningStatus() ohne Channel ist. Solche kommen bei mir praktisch gar nicht (bis auf den einen, siehe oben).

    "EPG scan max. channel number" steht bei mir auf 100.

    Was könnte bei dir noch anders sein als bei mir?

    • New

    > Was könnte bei dir noch anders sein als bei mir?

    Ich denke, mit EPGLinger = 0 müsste das auch bei Dir auftreten. Lass es einfach noch etwas länger laufen

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    • New

    Das lief jetzt hier den ganzen Tag ohne Fehler.

    Da bei dir der Fehler anscheinend immer durch den Aufruf aus cSchedule::Sort() auftritt, ersetze diese Funktion bitte mal durch

    Falls damit der Fehler bei dir nicht mehr auftritt, würde ich auch die restlichen Stellen, wo "hasRunning" vorkommt, entfernen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login