VDR Developer Version 2.5.1 - "Pattern Timer"

  • Den Patch fände ich gut, damit könnte ich zweigleisig fahren, mal mit, mal ohne VPS.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Jetzt interessiert mich noch, welchen Einfluss es auf "normale" Timer, also ohne VPS, hat, wenn ich im Aunahmemenü VPS aktiviere.

    Setup.UseVps hat keinen Einfluss auch "normale" Timer.

    MANUAL:

    Code
    1. Use VPS = 0 Defines whether a timer that is created from an EPG entry
    2. (by pressing the "Record" (red) key in the "Schedules"
    3. or "What's on now/next?" menu) will automatically use VPS
    4. if the event it is created for has a VPS time.

    Es wirkt sich also ausschließlich beim Anlegen eines Timers aus dem Menü heraus aus.


    Der oben angegebene Patch ist notwendig, damit auch bei Setup.UseVps=false alles wie gewünscht funktioniert.

    Danke für den Bug-Report!

  • Danke für die Erläuterung, hätte ich auch finden können/sollen;)


    Nebenbei, ich habe mittlerweile 28 Patterntimer angelegt, die einwandfrei funktionieren! Danke für dieses Feature, :)


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Leider muss ich noch ein Problem melden:


    Auf einem anderen vdr folgende Programmierung: Eine Serie ohne @ angelegt, da ich auch die Nachtwiederholung aufgezeichnet werden soll. Zwischen Nachtwiederholung und nächster Folge keine weitere Programmierung. Nach der Nachtwiederholung fährt der Rechner runter bevor der nächste Timer angelegt wird, dass kann ich im Protokoll nachvollziehen. So wird die mächste Folge verpasst.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Das könnte dann erledigt sein, wenn Pattern Timer auch direkt auf Veränderungen der Timer-Liste reagieren. Momentan ist es so, dass ein Pattern Timer nur dann "spawnt", wenn sich die EPG-Daten des betreffenden Kanals ändern. Ich werde das noch so machen, dass das auch bei jeder Änderung der Timer-Liste passiert (das Beenden eines Timers verursacht ja auch eine solche Änderung).

    Behalte diesen Fall bitte im Auge und verifiziere es mit der nächsten Version von VDR (ich bin momentan an einer anderen Ecke tätig, daher wird es noch ein paar Tage dauern damit).

  • Aufgrund der EPG-Änderungen auf "Das Erste" heute Abend verschiebt sich extra 3, VPS würde das erledigen, ohne habe ich jetzt 2 Einträge, den Alten und den Verschobenen, der Alte müsste dann gelöscht werden.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • jsffm Kannst zum Thema "Pattern Timer spawnt nicht sofort nach Änderung" bzw. "...nach beendeter Aufnahme" bitte mal das hier testen:

  • Danke, werde ich auf meinem Testsystem, wo das Problem auftrat, einbauen.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ist eingebaut, die gleiche Konstellation wird verm. in der Nacht Mo-Di auftreten.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • jsffm Kannst zum Thema "Pattern Timer spawnt nicht sofort nach Änderung" bzw. "...nach beendeter Aufnahme" bitte mal das hier testen:

    Hat funktioniert, jetzt hat er den Timer angelegt, bevor er runterfährt. Damit wird der Wakup korrekt gesetzt. :tup


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Es wäre nicht schlecht, wenn bei Aufnahmestart der EPG auf Verschiebung überprüft wird und gegebenenfalls der Timer korrigiert wird.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Auf Testsystem eingespielt, werde das im Auge behalten.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Code
    1. 1:T-8468-515-2001:MTWTFSS:0000:2359:50:99:{Deutschland von oben}TITLE:

    Dieser Eintrag erzeugt mehrere Einträge zur gleichen Sendung. ZDF HD DVB-T


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Einen hab ich noch ;)

    Code
    1. 17:T-8468-515-2001:2021-01-22:0440:0510:50:99:Deutschland von oben:


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Sind doch noch mehr da, die ich deaktiviert habe:

    Code
    1. vdr3-2 vdr-2.5.1 # svdrpsend lstt | grep "Deutschland von oben"
    2. 250-158 0:47:MTWTFSS:0000:2359:50:99:{Deutschland von oben}TITLE:
    3. 250-161 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
    4. 250-162 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
    5. 250-167 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
    6. 250-168 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
    7. 250-170 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
    8. 250-171 17:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
    9. 250 172 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Das Problem hier ist, dass der eigentlich aufzunehmende Event sehr kurz ist (5 Minuten) und der Timer mit seinen 10 Minuten Nachlaufzeit auch den nachfolgenden Event (der 10 Minuten dauert) vollständig überlappt. In cTimer::SetEventFromSchedule() greift daher die Bedingung "if overlap is the same, we take the longer event"; beide Events werden zu 100% überlappt, und der zweite ist der Längere.

    Damit wird dem Timer der zweite Event zugewiesen, und der erste hat keinen Timer mehr. cTimer::SpawnPatternTimers() erzeugt daher einen neuen Timer und das Spiel beginnt von vorne. Mit VPS könnte man das zwar auf diesem Kanal umgehen, aber das ist keine allgemeine Lösung.


    Im konkreten Fall hilft erstmal, die Timer-Nachlaufzeit auf unter 10 Minuten zu verkürzen.

    Um das Problem allgemein für Aufnahmen ohne VPS in den Griff zu bekommen werde ich wohl dafür sorgen müssen, dass die Vor- und Nachlaufzeit des Timers immer klein genug ist, damit weder der vorherige noch der nachfolgende Event zu 100% überlappt wird.

    Als "Notbremse" könnte in cTimer::SpawnPatternTimers() auch noch geprüft werden, ob es bereits einen "gespawnten" Timer mit diesen Einstellungen gibt - falls es noch aus irgendwelchen anderen Gründen aus dem Ruder laufen sollte...