Timer bei Sommer-/Winterzeit Umstellung (Openelec/Xbmc/Kodi) [gelöst]

  • Hallo Zusammen,


    ja, ich habe im Forum gesucht. Ich habe keine passende Themen gefunden. Mein Openelec System hat VDR als Backend und es läuft zuverlässig und startet auch bei eingestellten Timern das System. Die Aufnahmen laufen und gehen. Soweit so gut.


    Zum Thema habe ich hauptsächlich hier im Forum das Problem angetroffen, dass Aufnahmen die während der Zeitumstellung geplant waren daneben gegangen sind. Das ist nicht mein Problem. Das ist wohl auch eine ganz andere Baustelle.


    Mein Problem: Wenn ich Sendungen zur Aufzeichnung plane und diese dann nach dem Zeitwechsel aktiv sein soll, sind grundsätzlich die Timer um eine Stunde versetzt. Das System läuft auf UTC Zeit und die Timer werden auch als solches gespeichert.


    Beispiel vom letzten Wechsel: Supernatural jeden Donnerstag von 21:00 bis 21:45. nach dem Wechsel war die Aufnahme von 20:00 bis 20:45. Was natürlich falsch ist.


    Ist diese Problem bekannt? Gibt es dafür eine Lösung? Ich habe beim letzten mal alle Timer neu setzten müssen. Möchte dies nicht wieder machen im März. Timer wurden über die Kodi/Xbmc Oberfläche gesetzt.


    Übrigens war dies meine erste Zeitumstellung mit VDR.

  • Die meisten nutzen sicherlich das vdr-Plugin epgsearch, um solche Serien per Suchtimer zu programmieren (da bietet sich dann auch live an, um das ganze schön per Weboberfläche zu programmieren). Wenn dann das neue EPG mit den "richtigen" Zeiten reinkommt, werden die Timer automatisch angepasst. Ich hab da aber noch nie drauf geachtet und auch noch nie ein Problem gehabt.


    Lars.

  • Also nun gab es wieder eine Zeitumstellung und nun sieht das log folgend aus:



    Wie man unschwer sehen kann, wird vdr heute "The Walking dead" ab 22 Uhr aufnehmen (Also 1 Stunde zu spät)... vdrsearch ist aktiviert. Timer über die "Kodi" Oberfläche gesetzt.
    timer.conf sieht so aus:

    Code
    1:S19.2E-133-12-126:-T-----:2140:2233:50:99:Helix:
    1:S19.2E-133-12-126:--W----:2050:2143:50:99:Haven:
    1:S19.2E-133-12-126:--W----:2140:2233:50:99:Haven:
    1:S19.2E-133-10-124:M------:2000:2047:50:99:The Walking Dead:
    1:S19.2E-133-13-110:----F--:2000:2102:50:99:House of Cards:


    Darüber hinaus sind nun alle Aufnahmen aus der Winterzeit mit einer Stunde versatz angezeigt. Wo kann man bei dieser Problematik nun ansetzen. Meine alte Dreambox hat hier kein Problem gehabt. Fragen und weitere Anregungen sind erwünscht.


    Mod.: Bitte Code-Tags und Spoiler bei langen Ausgaben verwenden!

  • A propos OpenElec: vom Upgrade auf die 5.0.7 rate ich im Augenblick ab, bei mir crasht Kodi sofort nach dem Start. Ich musste auf 5.0.6 zurueck.


    uwe

    server: yavdr trusty testing, 2 * L5420, 32GB, 64TB RAID6 an OctopusNet (DVBS2- 8 ) + minisatip@dsi400 (DVBS2- 4 )
    frontends: kodi und xine

  • Hi,
    Es ging Mini darum, dass man im epgsearch Plugin Suchtimer bequem setzen kann, nur Serienname angeben und fertig... Alles andere macht er dann.
    Dann klappt auch dad updaten. Das xbmc Frontend nimmt kaum wer für vdr... MfG Stefan


    Gesendet von meinem HTC One mit Tapatalk 2

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Mir ist schon klar, worum es mit epgsearch geht. Dies ist aber überhaupt nicht die Frage bzw die Antwort. Diese Aussage ist vergleichbar mit: benutze ein iPhone, dann hast du die Probleme mit Android nicht.


    Das Kodi Frontend nutz kaum jemand? Wie kommst du zu dieser Behauptung? Dies mag vielleicht für dieses Forum gültig sein, mehr auch nicht.


    So wie ich das also verstehe, ist es eine fehlerhafte Implementierung des Timers / der Aufnahmen in Verbindung mit UTC und der Zeitumstellung.


    Mir ist dabei aufgefallen, dass das Live Plugin ebenfalls auschliesslich UTC Zeiten anzeigt.


    Grundsätzlich habe ich den Verdacht, dass VDR Probleme mit der UTC Zeit hat und besser mit Lokaler-Zeit läuft. Ich meine, auschliesslich das System bzw. die RTC muss mit UTC befüttert werden, wenn das System mit UTC läuft. Der Rest, also OSD, EPG, Aufnahmen usw. brauchen nur die Lokale-Zeit. Mit Linux ist das nur leider usus, dass die Systeme mit UTC Zeit laufen.


    Aber letztendlich zielt meine Ursprungsfrage darauf hinaus, ob ich irgendwo etwas einstellen muss, damit die "Serien-Timer", die über OSD eingestellt werden auch eine Zeitumstellung überleben und meine Aufnahme vom letzten Samstag auch nach der Zeitumstellung noch anzeigt, dass sie um 20:15 gestartet wurde.

  • Mein vdr läuft schon immer mit UTC im BIOS, allerdings nutze ich nicht die vdr-eigenen Wiederholungstimer, sondern die von epgsearch, das dann einzelne Timer anlegt.
    Man müsste mal die vdr-eigenen Wiederholungstimer untersuchen. Leider hab ich da gerade keinen Überblick, wie die arbeiten, da müsste ich mich erst einlesen. Das wird vor Ostern wahrscheinlich nichts.


    Lars.

  • Mir ist dabei aufgefallen, dass das Live Plugin ebenfalls auschliesslich UTC Zeiten anzeigt.


    Dann wäre mein erster Verdacht, dass die Zeitzone auf dem Rechner falsch gesetzt wurde.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Dann wäre mein erster Verdacht, dass die Zeitzone auf dem Rechner falsch gesetzt wurde.


    Das würde auch die falschen Timer erklären. Woher soll das System und die Anwendungsprogramme (VDR) sonst wissen dass gerade Sommerzeit ist.


    Ich tippe darauf dass gar keine Zeitzone gesetzt ist, auch wegen der Aussage:


    Zitat von dreamer

    Mit Linux ist das nur leider usus, dass die Systeme mit UTC Zeit laufen.


    Ich habe jedenfalls noch nie einen Linux-Desktop vor mir gehabt der die Zeit in UTC angezeigt hat. Moment, doch einen - bei einem Hobby-Astronom, aber der Mensch ist kein Maßstab da sogar seine Armbanduhr ständig UTC anzeigt.


  • Man müsste mal die vdr-eigenen Wiederholungstimer untersuchen. Leider hab ich da gerade keinen Überblick, wie die arbeiten, da müsste ich mich erst einlesen.


    Diese funktionieren einwandfrei mit Zeitumstellung. Verwende ich seit Jahren!


    CU
    Oliver

  • Diese funktionieren einwandfrei mit Zeitumstellung. Verwende ich seit Jahren!

    Wobei es für mich von der Prgrammlogik so aussieht, als würden die Wiederholungstimer des VDR aufgrund des Format der timers.conf nur richtig funktionieren, solange alle Sender die gleiche relative Zeitverschiebung zwischen Sommer- und Winterzeit zum gleichen Zeitpunkt mitmachen. Wenn man z.B. in Ägypten einen VDR in Lokalzeit betreiben würde, würden Wiederholungstimer für deutsche Sender, die in einer Phase erstellt wurden, wo beide Zeitzonen durch Sommer- bzw. Winterzeit gleich verschoben sind, doch eigentlich in den Phasen, wo das nicht der Fall ist (also zwischen dem letzten Sonntag im März und den letzen Freitag im April sowie zwischen dem letzten Freitag im September bis zum letzten Sonntag im Oktober) je eine Stunde von der realen Sendezeit abweichen.


    Eigentlich bekommt man die Start- und Stoppzeiten einer Sendung aus dem EPG als UTC-Timestamp, weshalb der VDR theoretisch gar nicht von einer gesetzten Zeitzone abhängig sein müsste (und man wäre nebenbei die Probleme bei der Zeitumstellung los), wenn die Vereinfachung mit der Nutzung der Lokalzeit für (Wiederholungs)timer nicht existieren würde...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Lasse mich da gerne korrigieren, aber imho werden die EPG-Daten nicht in UTC, sondern in localtime gesendet. Daher das Schlamassel bei Aufnahmen zwischen 2 und 3 Uhr in der Nacht der Zeitumstellung.


    Falls die Daten tatsächlich in UTC daher kommen, verstehe ich nicht, wieso die Timer-Engine mit localtime und nicht mit UTC arbeitet.

  • Falls die Daten tatsächlich in UTC daher kommen, verstehe ich nicht, wieso die Timer-Engine mit localtime und nicht mit UTC arbeitet.

    Also ich hatte das Kapitel 5.2.4 in http://www.etsi.org/deliver/et…_40/en_300468v011301o.pdf so verstanden, dass man da mit der Start-Zeit in UTC rechnen kann.
    In der epg.data liegt die Start-Zeit ja auch in UTC vor: http://vdr-wiki.de/wiki/index.php/Epg.data#E und die End-Zeit bekommt man durch einfache Addition der Dauer zur Start-Zeit.


    Ich kann mir das nur so erklären, dass da die Berechnung der Wiederholungstimer erleichtert werden sollte (was sonst mit verschiedenen Zeitzonen vermutlich etwas komplexer wird, und so ähnlich wie die RRULE aus RFC 2445 funktionieren müsste).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ok - demnach ist Startzeit eindeutig UTC.


    Die Berechnung der nächsten Startzeit eines Wiederholungstimers benötigt natürlich Localtime, denn während der Sommer-/Winterzeitumstellung ist der Tag eine Stunde kürzer/länger.


    Ich fürchte, wie man es auch macht, wird es wohl immer irgendwelche Spezialfälle geben. ..

  • Also bei mir hatte es sämtliche Timer am Sonntag l. Woche zerbröselt - für Montag war wieder alles i.O.


    Der Server auf dem der vdr läuft ist headless und hat epgsearch und live an Bord. Die Timer waren per epgsearch gesetzt. Beim Tatort z.B. stand der Timer auch kurz vor Beginn der Sendung (20:05) immer noch auf 21:13...


    Ich bin mir zwar sicher, dass ich beim Installieren des Systems (debian) die Zeitzone korrekt gesetzt hatte (denn die Zeitumstellung selbst klappt seit Installation einwandfrei - hab aber zur Sicherheit nochmal reconfigured (tzdata). ich meine mich sogar zu erinnern, dass Timer nach Umstellung auf die WInterzeit korrekt waren letztes Jahr.


    Jetzt muss man wieder bis Oktober warten und dann nochmal schauen...

  • Also ich verwende OpenElec und so wie es ausschaut, wird in der Tat keine Lokalisierung verwendet. Der Befehl "date" gibt als Zeitzone UTC aus. Das wäre zumindest eine Erklärung für das Live Plugin.


    So wie ich es verstehe, wird in Kodi eine Zeitzone eingestellt, daher auch grundsätzlich die richtige Zeit auf der GUI. Gibt es eine Möglichkeit in den setup.conf oder ähnliches eine Zeitzone zu definieren? Dies wird aber möglichweise das Ursprungsproblem nicht beheben.

  • Der vdr arbeitet nicht mit einer eigenen Zeitzone, er nimmt immer die des Systems. Warum OpenElec ohne läuft, erschließt sich mir nicht. Auch nicht, dass man in Kodi eine eigene einstellen kann...
    Es hilft also nur, die System-Zeitzone richtig einzustellen.


    Lars.

  • Da OpenElec scheinbar per default als lokale Zeit mit UTC arbeitet, habe ich mal das System auf CEST umgebogen. So wie ich damit das System beobachtet habe, dürften alle Probleme behoben sein, da die timer.conf nicht mit UTC arbeitet, wie von mir angenommen, sondern mit der lokalenzeit. Damit dürfte mit der Zeitumstellung alle timer dies sauber überleben. Ebendfalls die Aufnahmen. Wissen sollte ich das aber erst nach der Umstellung im Oktober. Bis dahin klär ich die Festlegung auf UTC Zeit direkt mit OE.

  • So, nun die endgültige Klärung: Beim Upgrade von OpenElec 4.0.x auf 4.2.x gab es wohl einen Bug, der dazu führte, dass die Zeitzone nicht mehr gesetzt wurde. Neuinstallationen betraf dies nicht. Nachdem ich in Kodi die Zeitzone neu gesetzt hatte, war die Zeitzone im System auch richtig gesetzt. Nun sollte mein Problem auch gelöst sein.

Jetzt mitmachen!

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