Timer Insanity?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Der Spuk für März ist zwar vorbei, aber diese Addition von 2 Tagen kann im nächsten Oktober genauso zuschlagen, da ja auf Ungleicheit der Stundenangabe geprüft wird.
    • Schaue mal auf vuplus.com/sub/main.php
      Links unten...
      Weniger ist manchmal mehr!

      Mein Setup: aktuelles VTi Image mit MuteSpectator-MOD Skin. OScam-Update. Plugins: OpenWebIF, GraphMultiEPG, EPGRefresh, EPGImport, EPGSearch, TMDb. Interne HDD 1TB. LAN an Fritz!Box 7580. HD+02. EPG.dat, Picons, Image Backup, und BackUpSuite Daten im Flash. Dur-Line UK-124 Unicable LNB für Astra 19.2E (8 Tuner), Dur-Line UK-124 Unicable LNB für Astra 28,2E (4 Tuner), Inverto IDLB-QUDL42-UNI2L-1PP für Hot Bird 13E (4 Tuner), Dual DVB-C/T2 Tuner. FCC=Off.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von atreyou ()

    • Die lesen hier sowieso mit ;rolleyes:
      Weniger ist manchmal mehr!

      Mein Setup: aktuelles VTi Image mit MuteSpectator-MOD Skin. OScam-Update. Plugins: OpenWebIF, GraphMultiEPG, EPGRefresh, EPGImport, EPGSearch, TMDb. Interne HDD 1TB. LAN an Fritz!Box 7580. HD+02. EPG.dat, Picons, Image Backup, und BackUpSuite Daten im Flash. Dur-Line UK-124 Unicable LNB für Astra 19.2E (8 Tuner), Dur-Line UK-124 Unicable LNB für Astra 28,2E (4 Tuner), Inverto IDLB-QUDL42-UNI2L-1PP für Hot Bird 13E (4 Tuner), Dual DVB-C/T2 Tuner. FCC=Off.
    • Die sind sehr beschäftigt mit dem neuen VTi image - Nachfolger für VTi 8.0 & VTi 8.1 - warte in Ruhe ab!
      Weniger ist manchmal mehr!

      Mein Setup: aktuelles VTi Image mit MuteSpectator-MOD Skin. OScam-Update. Plugins: OpenWebIF, GraphMultiEPG, EPGRefresh, EPGImport, EPGSearch, TMDb. Interne HDD 1TB. LAN an Fritz!Box 7580. HD+02. EPG.dat, Picons, Image Backup, und BackUpSuite Daten im Flash. Dur-Line UK-124 Unicable LNB für Astra 19.2E (8 Tuner), Dur-Line UK-124 Unicable LNB für Astra 28,2E (4 Tuner), Inverto IDLB-QUDL42-UNI2L-1PP für Hot Bird 13E (4 Tuner), Dual DVB-C/T2 Tuner. FCC=Off.
    • An der timer.py hat sich in 8.2.2 gegenüber 8.0.0 nichts geändert.
      Somit besteht das Problem weiterhin.
      Sofern ich die Zeit dazu finde, versuche ich auch selbst, den richtigen Algorithmus dafür zu finden.
    • Das heißt, die "timer.py" stammt nicht vom VTI-Image?

      Hier nochmal ein Beispiel durch die Original-Funktion der timer.py gejagt:

      Quellcode

      1. Repeated: 32
      2. ProcessRepeated
      3. localrepeatedbegindate: Sat Mar 21 02:15:00 2015
      4. localbegin: Sat Mar 21 02:15:00 2015
      5. localend: Sat Mar 21 04:00:00 2015
      6. localnow: Sat Mar 28 15:00:00 2015
      7. Day: 5
      8. localbegin after addOneDay: Sun Mar 22 02:15:00 2015
      9. localend after addOneDay: Sun Mar 22 04:00:00 2015
      10. localbegin after addOneDay: Mon Mar 23 02:15:00 2015
      11. localend after addOneDay: Mon Mar 23 04:00:00 2015
      12. localbegin after addOneDay: Tue Mar 24 02:15:00 2015
      13. localend after addOneDay: Tue Mar 24 04:00:00 2015
      14. localbegin after addOneDay: Wed Mar 25 02:15:00 2015
      15. localend after addOneDay: Wed Mar 25 04:00:00 2015
      16. localbegin after addOneDay: Thu Mar 26 02:15:00 2015
      17. localend after addOneDay: Thu Mar 26 04:00:00 2015
      18. localbegin after addOneDay: Fri Mar 27 02:15:00 2015
      19. localend after addOneDay: Fri Mar 27 04:00:00 2015
      20. localbegin after addOneDay: Sat Mar 28 02:15:00 2015
      21. localend after addOneDay: Sat Mar 28 04:00:00 2015
      22. localbegin after addOneDay: Mon Mar 30 02:15:00 2015
      23. localend after addOneDay: Sun Mar 29 04:00:00 2015
      24. localbegin after addOneDay: Tue Mar 31 02:15:00 2015
      25. localend after addOneDay: Mon Mar 30 04:00:00 2015
      26. localbegin after addOneDay: Wed Apr 1 02:15:00 2015
      27. localend after addOneDay: Tue Mar 31 04:00:00 2015
      28. localbegin after addOneDay: Thu Apr 2 02:15:00 2015
      29. localend after addOneDay: Wed Apr 1 04:00:00 2015
      30. localbegin after addOneDay: Fri Apr 3 02:15:00 2015
      31. localend after addOneDay: Thu Apr 2 04:00:00 2015
      32. localbegin after addOneDay: Sat Apr 4 02:15:00 2015
      33. localend after addOneDay: Fri Apr 3 04:00:00 2015
      34. ProcessRepeated result
      35. Sat Apr 4 02:15:00 2015
      36. Fri Apr 3 04:00:00 2015
      Alles anzeigen

      => Der Timer endet bevor er startet.

      Bugreport an Vu+ abgeschickt.
      Die timer.py im aktuellen Original-Image unterscheidet sich nur gerinfügig von der im VTI-Image.
      Diese Unterschiede betreffen nicht dieses Problem.

      Der Bug schlägt übrigens laut meinen Tests nur im Frühling zu.

      Noch eine Frage: Wenn man eine der *.py Dateien ändert, wird dann automatisch die zugehörige *.pyo Datei aktualisiert?

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Yahexu ()

    • Laut meinen "Trockentests" reicht es, die beiden Zeilen mit "#" auszukommentieren:

      Quellcode

      1. # if localtime(mktime(newdate)).tm_hour != oldHour:
      2. # return (datetime.datetime(timedatestruct.tm_year, timedatestruct.tm_mon, timedatestruct.tm_mday, timedatestruct.tm_hour, timedatestruct.tm_min, timedatestruct.tm_sec) + datetime.timedelta(days=2)).timetuple()


      Wenn man eine der *.py Dateien ändert, wird dann automatisch die zugehörige *.pyo Datei aktualisiert?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Yahexu ()

    • Die Addition von zwei Tagen statt einem Tag, falls die Stunde nach der Addition unterschiedlich ist, ist auch in der aktuellen timer.py der Version 9.03 immer noch drin.
      Das heißt, bei der Umstellung von Winter- auf Sommerzeit können immer noch die Timer verdreht werden,
      so dass Anfang (z. B. original Fr 02:30 Uhr) und Ende (z. B. original Fr 05:00 Uhr) nach der Umstellung falsch herum an verschiedenen Tagen liegen
      (im Beispiel: Anfang Sa 02:30 Uhr, Ende Fr 05:00 Uhr).
      Ich habe nach dem Upgrade auf Version 9.03 wieder die beiden Zeilen aus der timer.py gelöscht.
    • Nachdem ich vergessen hatte nach den letzten Updates meine timer.py zu patchen (entfernen der Addition von zwei Tagen statt einem),
      hat der Fehler bei der jetzigen Sommerzeitumstellung wieder zugeschlagen.
      Die richtige Endzeit wäre der 01.04.2017 02:20 gewesen.
      Problematisch ist immer nur die Umstellung von Winter- auf Sommerzeit.
      Alternativ kann man darauf achten, keine Timeranfänge und -enden zwischen 02:00 und 02:59 zu platzieren.
      Dateien
      • InsaneTimer.png

        (47,36 kB, 5 mal heruntergeladen, zuletzt: )

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Yahexu ()