Mal wieder VPS

    Auch das kann das Log (weitgehend) erklären:

    Code
    Jul  2 02:18:08 rpi4s vdr: [1425755] timer 37 (32 0045-0215 VPS 'Sauerkrautkoma') finished with 0 errors
Jul  2 02:18:11 rpi4s vdr: [1425755] timer 37 (32 0045-0215 VPS 'Sauerkrautkoma') stop

    Aufnahme wird beendet. markad logt keinen VPS Event, selbst wenn 1 gekommen wäre, weil es im Status "ungültige Sequenz" ist.. Den VPS Event 1 vom VDR gibt es auch nicht im Log, also kam er auch nicht. Keine Ahnung, warum VDR hier die Aufnahme endet, vielleicht Folgefehler vom ungültigen Start.

    Code
    Jul  2 02:18:19 rpi4s vdr: [1425755] timer 37 (32 0045-0215 VPS 'Sauerkrautkoma') start

    Hier startet die Aufnahme neu, also muss VPS Event 4 gekommen sein (den der VDR aber nicht logt, weil keine Sequenz 1->2->4 und er direkt die "verspätete" Aufnahme startet. Gleiches Verhalten wie beim verspätetem Start). Wiederholt VPS Event 4 ist normal für eine noch laufende Sendung. Eigentlich bestätigt das den Verdacht, dass der VPS Event 1 bis jetzt noch nicht kam.

    Code
    Jul  2 02:18:25 rpi4s vdr: [1425755] markad: cStatusMarkAd::GetEventID(): recording <Sauerkrautkoma>, timer <Sauerkrautkoma>, eventID 37437, eventNextID 37438, timer start 1688251500 stop 1688256900

    ab jetzt ist markad wieder dabei.


    Code
    Jul  2 02:18:32 rpi4s vdr: [1518351] markad: ------------------------------------> new VPS VDR Event: ID: 37437, state: 4 -> running
Jul  2 02:18:32 rpi4s vdr: [1518351] markad: 00:00:06 state: 0, event: 37437, new state: -1 -> recording start after VPS timer start is invalid

    und bestätigt, dass VPS Event 4 kam. Ist aber gleich wieder raus wegen der ungültigen Sequenz.

    Code
    Jul  2 02:18:52 rpi4s vdr: [1518750] channel 32 (SWR BW HD) event So. 02.07.2023 00:45-02:15 (VPS: 02.07. 00:45) 'Sauerkrautkoma' status 1

    Jetzt kommt wirklich der korrekte VPS Event 1, der auch vom VDR gelogt wird. Das beendet die Aufnahme wieder und ergibt den letzten Schnipsel. Eigentlich müssen in deiner Aufnahme ca. 40s am Ende fehlen. Oder der VPS Stop Event kam zu spät.


    Ich bleibe bei meiner Vermutung: Wenn es 2 Min vor Timer Start ein freies Device gegeben hätte, wäre das korrekt abgelaufen.

    Hallo kls ,


    Kannst Du Dir das bitte mal ansehen? Also den syslog, den ich am 2. Juli 2023 gepostet habe?


    Es fehlt das VPS Startevent, was dann zu wiederholtem Aufnahme -start und -stop führt.

    kfb77 hat das ja schon analysiert.


    ~ 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

    Sorry, aber da hab ich momentan leider nicht die Zeit, mich da durchzuwuseln.

    Auf den ersten Blick auffällig ist


    Jul 2 02:18:11 rpi4s vdr: [1425755] timer 37 (32 0045-0215 VPS 'Sauerkrautkoma') stop


    ohne dass vorher eine Statusänderung des Events kam.

    VPS-Probleme debugge ich aber grundsätzlich nur, wenn sie im "plain vanilla" VDR, ohne irgendwelche Plugins, die da mitmischen, auftreten ;-).

    Zitat von kls

    ohne irgendwelche Plugins, die da mitmischen

    markad mischt nicht mit, sondern schaut nur zu.

    Ich logge nur die VPS Events um sie später ggf. als Schnitt Information zu verwenden. Ich ändere aber nie was an den Events.

    Es sieht so aus, als würde zwischen 00:45 und 00:48 ein Zustand vorliegen, in dem

    • Der Prozess, der entscheidet, ob eine VPS Aufnahme gestartet werden muss, zum Ergebniss "ja" kommt
    • Der Prozess, der entscheidet, ob eine VPS Aufnahme beendet werden muss, auch zum Ergebniss "ja" kommt

    Dadurch wird die Aufnahme gestartet, beendet, wieder gestartet, ...


    Die beiden oben genannten Prozesse sollten identische Kriterien verwenden, um das zu vermeiden


    ~ 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

    Es liegt an timers.c, cTimer::Matches(time_t t, bool Directly, int Margin):

    Code
                        if (event->Schedule()->PresentSeenWithin(EITPRESENTFOLLOWINGRATE)) // VPS control can only work with up-to-date events...
                       return event->IsRunning(true);

    Lösungsvorschlag:

    Die Zeile "if (event->Schedule()->PresentSeenWithin(EITPRESENTFOLLOWINGRATE)) ..." löschen, und einfach nur "return event->IsRunning(true);" stehen lassen.


    Warum ist diese Prüfung problematisch:

    Matches wird sehr oft aufgerufen. Und bei jedem Aufruf kann das Ergebnis von "PresentSeenWithin" unterschiedlich sein. Was dazu führt, dass manchmal VPS berücksichtigt wird, und manchmal nicht. Dann startet der Timer, und stopped, und startet, ...


    Lösungsmöglichkeiten:

    Wie gesagt, ich würde einfach PresentSeenWithin weglassen. Ist einfach :) und funktioniert :) .

    Andere Lösungsmöglichkeiten gibt es auch, die sind aber deutlich komplizierter.

    Es kann verschiedene Ursachen geben, warum "PresentSeenWithin" false zurückgibt. z.B.: vdr gerade gestartet, es konnte wegen anderer Aufnahmen nicht auf den Transponder getuned werden, timer wurde gerade angelegt, ...

    Man müsste also zunächst die Ursache herausfinden, und dann je nach Ursache unterschiedlich reagieren, z.B. VPS für den Timer dauerhaft ausschalten, ...


    kls , was meinst Du?


    ~ 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

    Gefällt mir nicht. Laut Standard soll die EIT present/following Table alle 2 Sekunden kommen. VDR wartet eh schon deutlich länger (10s). Wenn diese Daten nicht mehr kommen, heißt das doch, dass der Transponder nicht mehr empfangen wird und man sich auf den Wert von event->IsRunning() nicht verlassen kann.


    Ich würde vorschlagen, eher zu untersuchen, warum so lange nicht mehr auf den Transponder geschaltet wurde.

    Hi kls ,


    Beispiel, warum EIT present/following nicht kommt:

    • Sender: ARTE HD
    • VPS Zeit: 2:00
    • Timer start: 2:00
    • Timer end: 3:00

    Tatsächlich geht die Sendung aber nur bis 2:55. Dann geht der event Status auf 1, und VDR beendet den timer.

    Dann wird das device nicht mehr für ARTE HD benötigt (der timer ist ja beendet), und VDR nutzt das device zum EIT scan anderer Transponder.

    10 s später fällt auf, dass kein EIT present/following kommt.

    Um 2:56 startet VDR den timer erneut wegen timer end 3:00.

    Dann kommt wieder EIT present/following, mit Status 1. Und VDR beendet den Timer.

    Und das wiederholt sich dann bis 3:00 ...


    OK, es gibt eine Alternativlösung:

    • Wir zwingen das device für die komplette Timerzeit (2:00 bis 3:00) auf ARTE HD.
    • Wenn dann innerhalb der Timerzeit (2:00 bis 3:00) EIT present/following fehlt:
      • Fehlermeldung (damit untersucht werden kann, woran es liegt)
      • Timer wird dauerhaft auf non-vps umgestellt.


    Geht auch. Ich fand meinen Lösungsvorschlag aber einfacher und besser.


    ~ 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

    Es gibt noch ein weiteres Problem. Nehmen wir wieder oben genannten Timer.


    Beispiel 2:

    • Alle devices waren bis 2:01 mit anderen Aufnahmen höherer Priorität belegt.
    • Um 2:01 ist das EIT present/following nicht sichtbar, VDR startet den timer
    • 2 Sekunden danach erscheint das EIT present/following, status 1. VDR stoppt den timer. (der VPS start status kommt in diesem Beispiel erst um 2:05)


    Wenn wir jetzt oben genannte Alternativlösung implementieren, wird VPS für diesen Timer dauerhaft de-aktiviert. Ist unschön. Man müsste also prüfen, ob das Blockieren der Devices durch andere Aufnahmen die Ursache für das Fehlen von EIT present/following ist. Und, falls ja, einfach nichts tun/10s warten.


    Das kann man sicher alles sauber durchdenken, prüfen und implementieren. Ist aber nicht ganz trivial, fehleranfällig, ...


    ~ 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

    Verstehe ich da was falsch, oder hat die Vor- und Nachlaufzeit für den VDR keine Bedeutung?

    Es geht hier um VPS Timer, da darf es keine Vorlaufzeit geben um den VPS Event zuordnen zu können.

    Hi,


    anbei noch der Patch, den ich verwende.

    • Sehr einfach, VDR Interface wird nicht verändert -> Plugins müssen nicht neu compiliert werden
    • Löst die hier beschriebenen Probleme
    • Führt in der Praxis zu keinen neuen Problemen. Zumindest sind mir keine bekannt. Falls ihr welche findet, gerne hier posten.

    Wenn jemand eine bessere Lösung für die hier beschriebenen Probleme implementieren möchte, habe ich natürlich nichts dagegen.


    ~ Markus

    Zitat von kfb77

    Es geht hier um VPS Timer, da darf es keine Vorlaufzeit geben um den VPS Event zuordnen zu können.

    Ich meine, die Vor- und Nachlaufzeit, die der VDR den Kanal noch belegt, auch um VPS-Events während des Zeitraums empfangen zu können? Sodaß das Szenario, wonach Events verpaßt werden, weil der Transponder noch gar nicht/nicht mehr gelockt ist, verhindert werden kann...

    Das Hauptproblem scheint ja zu sein, wenn der Running-Status vor der Ende-Zeit des Events auf '1' geht.

    Vielleicht wäre das hier eine mögliche Lösung?

    Das wird also Lösung nicht ausreichen.


    Device = cDevice::GetDeviceForTransponder(Timer->Channel(), LIVEPRIORITY);

    müsste in jedem Fall noch durch

    Device = cDevice::GetDeviceForTransponder(Timer->Channel(), Timer->Priority() );


    ersetzt werden. Und dann müsste sichergestellt werden, dass während der kompletten Zeit des Timers (+ kleiner Vorlauf, also 1:59 - 3:00) ein device auf diesen Transponder getuned ist (mit der Priorität des Timers). Geht vermutlich mit vdr.c in Kombination mit occupied(). Ist TIMERDEVICETIMEOUT so lang, dass sichergestellt ist, dass vdr.c wieder an dieser Stelle vorbeikommt, bevor TIMERDEVICETIMEOUT abgelaufen ist? Sollte man noch einen Saveguard einbauen.


    Dann wäre das in #28 beschriebene Problem gelöst.


    Und man bräuchte noch eine Lösung für das in #29 beschriebene Problem.


    ~ 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

    Ich denke, #28 könnte man mit einem weiteren Flag


    tfVpsTimerInTimeframeWhereTransponderMustBeTunedToThisChannel


    (zusätzlich zu tfRecording) in cTimer lösen.


    cTimer::Recording() bekommt einen Eingabeparameter: cTimer::Recording(bool orDeviceMustBeTuned) als Eingabeparameter, und gibt dann, je nach dem wie der Eingabeparameter gesetzt ist, tfRecording oder (tfRecording | | tfVpsTimerInTimeframeWhereTransponderMustBeTunedToThisChannel) zurück.


    Dann müsste man noch an allen Stellen, an denen cTimer::Recording() aufgerufen wird, prüfen, welchen Wert der neue Eingabeparameter braucht.

    Und natürlich noch dafür sorgen, dass das Flag tfVpsTimerInTimeframeWhereTransponderMustBeTunedToThisChannel korrekt gesetzt ist.

    Und dass ein device mit timer->priority() auf den Sender getunt ist, so lange Recording(true) true zurückgibt.


    Wenn dann cTimer noch eine Methode "WasTunedToChannelForMoreThan10Seconds" bekommt, und das vor dem Aufruf von PresentSeenWithin(...) überprüft wird, könnte man vermutlich auch #29 lösen.


    Müsste gehen. Ist aber doch recht komplex, ev. habe ich etwas übersehen.


    ~ 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

    Hi,


    Anbei ein Update des Patches.

    Damit stellt vdr.c sicher, dass regelmäßig im InVpsMargin Zeitraum mit der Priorität des Timers auf den Transponder des Kanals getuned wird. Und TIMERDEVICETIMEOUT Sekunden auf dem Kanal getuned bleibt, um sicherzustellen, dass EIT present/following empfangen wird.

    VDR macht das im Abstand von TIMERCHECKDELTA. Wenn das so nicht ausreicht, kann man TIMERCHECKDELTA ja noch kleiner machen, und sollte dann auch TIMERDEVICETIMEOUT kleiner machen.


    z.B.

    Code
    TIMERCHECKDELTA = 5
TIMERDEVICETIMEOUT = 4

    TIMERDEVICETIMEOUT = 4 sollte reichen, weil EIT present/following ja mindestens alle 2 Sekunden gesendet wird, dann hat man noch 2 Sekunden Puffer.


    Die Aufgabe, sicherzustellen, dass der running status up to date ist hat damit vdr.c übernommen. Damit kann die entsprechende Prüfung in timers.c, die zu den hier beschriebenen Problemen führt, entfallen.



    ~ Markus

    Anbei ein Update des Patches.

    BlockedFor() gibt es nicht mehr, das macht jetzt cDevice::Occupied() .


    Und noch ein paar Korrekturen, ein Occupied() Device kann jetzt geswitched werden, falls ein anderer Timer das Device mit einer höheren Priorität benötigt.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden