[yavdr 0.5] [gelöst] falsches Handling von Timern bei Sommerzeit zu Normalzeit

    Hallo,

    ich hatte gestern eine aufnahem für 2:50 bis 3:15 uhr programmiert

    theoretisch hätte der timer 1:25h aufnehmen müssen da während der aufnahem die Zeit zurückgestellt wurde (war so im EPG, hatte die Sendung im EPG zur aufnahme selektiert)
    aber er hat nicht zum "ersten" 2:50 uhr gestartet sondern erst beim "zweiten" 2:50 uhr und die resultierende aufnahem ist 1h zu kurz
    da ich noch wach war habe ich gesehen das die aufnahem nicht gestartet ist obwohl vdr selbst 2:55 Uhr angezeigt hat, da ich schon recht müde war habe ich nicht an instant recording gedacht oder die startzeit weiter nach vorn zu verlegen, hab es einfach sein lassen und bin ins bett gegangen

    bevor ich das in der vdr ml vorbringe wollte ich es erst mal hier eiwerfen da yavdr doch erheblich gepatcht ist und wen kls dann verlangt es mit einem ungepatchten vdr nachzustellen wird es evtl. schwierig da man das nur schwer als ganzes nachbilden kann (vdr hat da sicher sonderregeln für sommer/winterzeit im code die man genau kennen müsste um ihm das unter zu jubeln)

    Einmal editiert, zuletzt von IG88 (30. Oktober 2012 um 17:32)

    Zitat von IG88

    (vdr hat da sicher sonderregeln für sommer/winterzeit im code die man genau kennen müsste um ihm das unter zu jubeln)


    Da hat VDR eigentlich keine besonderen Vorkehrungen, weil das einfach viel zu kompliziert wäre für diesen einen Fall pro Jahr ;)
    Es müsste ja dann bei jedem Timer zusätzlich noch gespeichert werden, ob es Sommer- oder Winterzeit sein soll, und das ist mir einfach zu aufwendig.
    Im Zweifelsfall also lieber die Aufnahme vor 02:00 Uhr beginnen und nach 03:00 Uhr enden lassen. Dann ist sie zwar u. U. zu lang, aber immerhin ist alles aufgenommen.

    Klaus

    Wie wird denn dein VDR für den Timer geweckt? Wenn es über das extb geht, würde ich da mal schauen, ob die Zeit durch das Skript richtig gesetzt wird. Nutzt das intern UTC oder verwendet es die Lokalzeit?

    Meine VDRs

    VDR 1: Point of View Ion-330-1, 2x Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, Ubuntu 18.04 (yavdr-ansible)
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 18.04 (yavdr-ansible), VDR 2.4.1, CIR-Empfänger
    Client 1: Raspberry Pi 2, Arch Linux ARM, VDR 2.3.8
    vdr-epg-daemon auf Cubietruck mit 32 GB SSD, Arch Linux ARM

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Willkommen im Club, mir hats gestern die Doctor Who Aufnahme versaut.

    Eigentlich sollte so was nicht passieren wenn intern immer mit UTC gearbeitet wird. Nu habe ich es versäumt zu schauen ob evtl. schon die EPG Daten fehlerhaft waren. Laut EPG Anzeige im VDR wurde die Länge von 70 Minuten angezeigt (was aber mit den Lokalzeitanzeigen natürlich nicht zusammen passte), aufgenommen wurde aber nur das Ende. Wobei epgsearch die Aufnahme als vollständig aufgezeichnet betrachtete und in die epgsearchdone.data übernommen hatte.

    Ich denke es liegt nicht an irgendwas yaVDR speziellen. Ich denke die EPG Daten waren schon kaputt.

    Zitat von kls

    Es müsste ja dann bei jedem Timer zusätzlich noch gespeichert werden, ob es Sommer- oder Winterzeit sein soll, und das ist mir einfach zu aufwendig.

    Wieso? UTC, da brauchts sowas nicht.

    Zitat von seahawk1986

    Wie wird denn dein VDR für den Timer geweckt? Wenn es über das extb geht, würde ich da mal schauen, ob die Zeit durch das Skript richtig gesetzt wird. Nutzt das intern UTC oder verwendet es die Lokalzeit?

    Mein VDR lief schon und hat den selben Fehler gezeigt. Und epgsearch hat die Aufnahme als vollständig erkannt.

    cu

    hi,

    wenn vdr gar keine vorkehrungen trifft hätte er ja beim ersten 2:50 starten müssen, hat er aber nicht deshalb die annahme das da was anderes schief läuft
    wenn er die aufnahme gestartet hätte und dann nach dem rücksprung auf 2 uhr wieder gestopt (weil die startzeit nicht erreicht ist) wäre es ja logisch aber so, zeit ist ran und timer startet nicht
    habe ja daneben gesessen und gleich noch mal aus dem epg eintrag einen neuen timer erzeugt (2:55 uhr)

    wundert mich echt das sich in >10 jahren vdr kein perfektionist gefunden hat der dafür code beigesteuert hat

    edit: der vdr lief, es ging noch nicht mal um's aufwachen nur reines timerhandling

    Zitat von IG88

    hätte er ja beim ersten 2:50 starten müssen

    Es gibt kein "erstes" und "zweites" 2:50. Das sind nur Ziffern die Dargestellt werden, intern wird mit UTC gearbeitet, und da gibts IMMER eindeutige Zeiten. Ein Blick in die epg.data wäre hilfreich gewesen.

    Ich vermute der Sender hat kaputte EPG Daten gesendet. Ich war gestern Abend nur zu müde das grosse Debuggen anzufangen und hatte einfach gehofft das es schon passen wird.


    Edit: Ich hab ja noch das Backup der epgsearchdone.data, daraus

    Code
    R 1351385700 4200 63
C S19.2E-133-1-16
T Doctor Who
S 05x01 Fünf vor Zwölf
D modEPG: Doctor Who~05x01 Fünf vor Zwölf|modEPG_ns: 05x01 Fünf vor Zwölf|modEPG_os: Fünf vor Zwölf
@ <epgsearch><channel>55 - Fox</channel><searchtimer>Doctor Who</searchtimer><start>1351385400</start><stop>1351390500</stop><s-id>63</s-id><eventid>14730</eventid></epgsearch>
r

    info.vdr

    Laut length.vdr hatte die Aufnahme ne Länge von 9 Minuten.


    Also zumindest hat epgsearch nen Bug. Das scheint gesichert.
    http://projects.vdr-developer.org/issues/1117


    Edit: Ich häng mal das Log an, das ist lustig ;) Da liegt wohl mehr im Argen
    (Auf die relevanten Sachen gekürzt)

    cu

    Zitat von kls

    Es müsste ja dann bei jedem Timer zusätzlich noch gespeichert werden, ob es Sommer- oder Winterzeit sein soll, und das ist mir einfach zu aufwendig.


    Könnte man die Timer-Zeiten in der timers.conf nicht einfach als Unix-Timestamp ablegen? EPGsearch arbeitet doch auch damit und in der info-Datei können sie auch enthalten sein. Dann hat man eine vollständig lineare Vergleichsmöglichkeit ohne Vorwärts- oder Rückwärtssprünge... IMHO ist es unpraktisch da mit Daten aus einer Relation statt aus einer Funktion zu arbeiten.

    Meine VDRs

    VDR 1: Point of View Ion-330-1, 2x Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, Ubuntu 18.04 (yavdr-ansible)
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 18.04 (yavdr-ansible), VDR 2.4.1, CIR-Empfänger
    Client 1: Raspberry Pi 2, Arch Linux ARM, VDR 2.3.8
    vdr-epg-daemon auf Cubietruck mit 32 GB SSD, Arch Linux ARM

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi,

    es ist seltsam, aber diesmal bin ich nicht von dem Problem betroffen. Ganz im Gegenteil:


    wie man sehen kann, läuft die 007-Aufnahme über den Zeitsprung hinweg und die Aufnahme Spooks, die um 2:05 starten sollte fängt mit dem 2. Vorkommen (laut Log) von 2:05 an und scheint in Ordnung zu sein.

    Habe natürlich keine Ahnung, ob die Sendung 2mal ausgestrahlt wurde.
    Aber vielleicht hängen die Probleme ja wirklich mit den EPG-Daten zusammen?

    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    hallo,

    ich habe das mal auf gelöst gesetzt da es wohl an falschen daten im epg lag, es gab ja leute bei denen das auf anderen sendern funktioniert hat und vermutlich waren die utc zeiten im epg falsch vom sender hinterlegt
    was sich ja mit meiner beobachtung deckt das beim "ersten" 2:55 der timer der mit 2:50 zu sehen war noch nicht lief und auch beim neu erzeugen nicht anlief, die utc zeit war einfach noch nicht erreicht und 1h später war die utc zeit ran und der timer lief los

    Moin!

    Wenn ich eine Sendung zu dieser gewissen Stunde aufnehmen möchte, programmiere ich immer alle drumherum liegenden Sendungen mit, damit sich die Chance vergrößert, genug Material beisammen zu haben, damit man sich was zusammenschneiden kann. :)

    Lars.

    vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
    hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
    Plugins: | avahi4vdr | dbus2vdr | dynamite | epg2timer | noepg | pvrinput | sundtek |

    Zitat von geronimo

    Oct 28 02:02:19 vdr vdr: [2968] channel 2 (Das Erste HD) event Son 28.10.2012 02:00-02:05 (VPS: 28.10. 02:40) 'Tagesschau' status 4 Oct 28 02:03:32 vdr vdr: [2991] recording to '/var/lib/video.00/James_Bond_007_-_Diamantenfieber/2012.10.28-00:45-So/2012-10-28.00.40.2-0.rec/00068.ts'

    Mein Held :) => wenn du es jetzt noch hoachlaedst :D


    Gruss gerd

    vdr => p8b75-m lx / pentium g2020t / 8 GB Ram / zotac gt 630 / cine S2 V5.5 / 60 gb ocz ssd / 640 gb wd scorpio blue / display noritake 256x64-3900 / chenbro PC71023 gehaeuse / yavdr stable / softhddevice

    spielsystem => p8b75-m le / intel core i3 3220T / ubuntu lts 14.04 / 16 GB ram / zotac gt 630 / cine S2 V6.2 / yavdr stable pakete / softhddevice / pulseaudio+alsa

    spielwiese => Zotac Zbox ID45 / 120 GB mSATA / via Satip => Octopus Net / yavdr stable / softhddevice

    Hai,

    was ich witzig finde - die Aufnahme, die über die Zeitumstellung lief (007) wurde bei Schneiden länger :D

    Bei epgsearch-Timern habe ich idR 45 Minuten Zugabe, d.h. beim Schnitt wird die Aufnahme min. um diesen Betrag kürzer.
    Nicht so an diesem Tag zu dieser Stunde ...

    Gruß Gero

    Zitat von kls


    Da hat VDR eigentlich keine besonderen Vorkehrungen, weil das einfach viel zu kompliziert wäre für diesen einen Fall pro Jahr ;)
    Es müsste ja dann bei jedem Timer zusätzlich noch gespeichert werden, ob es Sommer- oder Winterzeit sein soll, und das ist mir einfach zu aufwendig.
    Im Zweifelsfall also lieber die Aufnahme vor 02:00 Uhr beginnen und nach 03:00 Uhr enden lassen. Dann ist sie zwar u. U. zu lang, aber immerhin ist alles aufgenommen.

    Klaus


    Moin Klaus,
    ich wärme das hier nochmal auf, da das Thema kommenden Sonntag wieder ansteht und - wie soll's auch anders sein - natürlich wieder mal zu Problemen mit durch EPG-Search erzeugten Timern führt.

    Sofern ich zufällig rechtzeitig die Timer sehe kann ich manuell die Auto-Timer löschen und manuell neu anlegen (gerade gemacht) - mit einer Stunde Nachlauf und abgeschalteter Überwachung (weil's onst ja vollautomagisch wieder in die Hose geht). Auch wenn das einmal im Jahr passiert - da es mir schon oft mir wichtige Aufnahmen zernagelt hat ist das einfach keine Lösung.

    Letztlich erscheint mir das Problem hausgemacht - zumindest meine ich mal gelesen zu haben, dass die EPG-Daten in GMT übertragen werden. Damit sollte es diese Zeitumstellungsprobleme doch gerade mal gar nicht geben. Zumindest, wenn auch die Timer diese Zeiten 1:1 übernehmen und bei laufender Aufnahme mit einer auf GMT umgerechneten Uhr vergleichen.

    Letztlich brauche ich doch die Lokalzeit dann doch nur noch für die Anzeige beim Anwender oder für die manuelle Eingabe (und bei letzterer muss ich dann entweder umschalten können, ob ich GMT oder Lokalzeit eingebe) oder mit der doppelten Stunde leben...

    Ist das mit dem EPG in GMT eigentlich Standard, d. h. wie halten es denn die Briten? Solange ich die ReelBox noch hatte gab es mit deren VDR-Variante auf den britischen Kanälen ja auch nur Probleme.

    Viele Grüße,
    Torsten

    "The day Microsoft makes something that doesn't suck is probably
    the day they start making vacuum cleaners" - Ernst Jan Plugge
    __________________
    Torsten Lang

    Zitat von torsten lang


    ich wärme das hier nochmal auf, da das Thema kommenden Sonntag wieder ansteht und - wie soll's auch anders sein - natürlich wieder mal zu Problemen mit durch EPG-Search erzeugten Timern führt.

    Sofern ich zufällig rechtzeitig die Timer sehe kann ich manuell die Auto-Timer löschen und manuell neu anlegen (gerade gemacht) - mit einer Stunde Nachlauf und abgeschalteter Überwachung (weil's onst ja vollautomagisch wieder in die Hose geht). Auch wenn das einmal im Jahr passiert - da es mir schon oft mir wichtige Aufnahmen zernagelt hat ist das einfach keine Lösung.


    Wäre es denn nicht möglich, EPG-Search so zu ändern, daß es bei Timern, die zu den kritischen Zeiten beginnen bzw. enden, jeweils eine Stunde vorne und/oder hinten dranhängt?

    Zitat


    Letztlich erscheint mir das Problem hausgemacht - zumindest meine ich mal gelesen zu haben, dass die EPG-Daten in GMT übertragen werden. Damit sollte es diese Zeitumstellungsprobleme doch gerade mal gar nicht geben. Zumindest, wenn auch die Timer diese Zeiten 1:1 übernehmen und bei laufender Aufnahme mit einer auf GMT umgerechneten Uhr vergleichen.


    Dabei unterschätzt du aber wohl den Erfindungsreichtum der Sendeanstalten, wenn es darum geht, Wege zu finden, die EPG-Daten zu "verbocken". Es ist schon oft vorgekommen, daß nach der Zeitumstellung die EPG-Daten eine Stunde "daneben" waren.

    Zitat


    Ist das mit dem EPG in GMT eigentlich Standard, d. h. wie halten es denn die Briten?


    Die Zeitangaben in den EPG-Daten sind laut Standard in UTC (was GMT entspricht).

    Klaus

    Zitat von kls

    Dabei unterschätzt du aber wohl den Erfindungsreichtum der Sendeanstalten, wenn es darum geht, Wege zu finden, die EPG-Daten zu "verbocken". Es ist schon oft vorgekommen, daß nach der Zeitumstellung die EPG-Daten eine Stunde "daneben" waren.


    Hallo Klaus,
    nicht nur die EPG-Daten. Ich habe auch schon mal meine sämtlichen Silvester-Aufnahmen verloren, weil die Sendeanstalt nach dem Jahreswechsel ein ganzes Jahr in der ausgestrahlten Uhrzeit übersprungen hatte.

    Wenn es an der Quelle gründlich verbockt wird kann man halt wenig machen...

    Viele Grüße,
    Torsten

    "The day Microsoft makes something that doesn't suck is probably
    the day they start making vacuum cleaners" - Ernst Jan Plugge
    __________________
    Torsten Lang

    Hier die neueste Variante bei "Das Erste HD": die haben einfach aus mehreren Sendungen *einen* großen Event gemacht, der die kritische Stunde überbrückt (obwohl mir die Logik dahinter auch nicht ganz klar ist...).

    Am besten wäre es sicherlich, die ganze Zeitumstellung komplett abzuschaffen und immer bei der Sommerzeit zu bleiben...

    Hallo Klaus,
    Fazit von heute nacht: Trotz manuell eingestellter Timer ohne Überwachung und künstlich verlängerter Endezeit nach 03:00 funktioniert es einfach nicht - die Aufnahmen, die während der Umstellung stattfanden, waren unvollständig. Konkret: Aufnahmestart 01:35, Ende 03:10, sollte eigentlich zu einer Aufnahmezeit von 3:35 führen. Faktisch wurden aber nur 1:35 aufgenommen...

    Viele Grüße,
    Torsten

    "The day Microsoft makes something that doesn't suck is probably
    the day they start making vacuum cleaners" - Ernst Jan Plugge
    __________________
    Torsten Lang

    Zitat von torsten lang

    Hallo Klaus,
    Fazit von heute nacht: Trotz manuell eingestellter Timer ohne Überwachung und künstlich verlängerter Endezeit nach 03:00 funktioniert es einfach nicht - die Aufnahmen, die während der Umstellung stattfanden, waren unvollständig. Konkret: Aufnahmestart 01:35, Ende 03:10, sollte eigentlich zu einer Aufnahmezeit von 3:35 führen. Faktisch wurden aber nur 1:35 aufgenommen...

    Tja, es bleibt mystisch ;-).
    Möglicherweise checkt VDR nicht für Start- und Endezeit getrennt, ob es Sommer- oder Winterzeit ist.
    Das Problem tritt einfach zu selten auf, als daß da ein wirklicher Leidensdruck aufgebaut werden würde ;-).

    Klaus

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden