Timer Insanity?

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

    • Timer Insanity?

      Kann es sein, dass der Timer-Sanity-Check wegen der Zeitumstellung überreagiert und Amok läuft?
      Tunerkonfiguration: 2x Dual Tuner mit zwei Kabeln - Tuner A Astra 19.2 - Tuner B verbunden mit A - Tuner C wie Tuner A - Tuner D verbunden mit C

      Heute Morgen hatte (unter anderem) ein Wiederholungstimer, der seit Wochen für Donnerstag 2:50 Uhr bis 6:10 Uhr programmiert ist und läuft, eine Laufzeit von -1736 Minuten (negativ!)
      und ließ sich auch durch Änderung von Start- und Endzeit nicht vom Gegenteil überzeugen.
      Nach Neustart der Vu+ Duo² hatte dieser Timer dann eine Laufzeit von 0 Minuten und ging von 2:50 Uhr bis 2:50 Uhr.
      Ein zweiter Timer hatte das gleiche Problem.

      Anderes Phänomen: Ich wollte einen Timer für Montag 30.03.2015 21:50 Uhr bis 00:40 Uhr hinzufügen.
      Für diesen Timer wurden mir Konflikte angezeigt: Montag 20:05 bis 21:25, Montag 00:01 bis 05:40, Montag 20:02 bis 23:35
      Dass letzterer theoretisch in Konflikt stehen könnte (es sind genügend Tuner da) ist klar, aber was ist mit den ersten Beiden?

      Das Problem aus Timeranzeige im EPG bei Dauer von Sonntag bis Montag unvollständig besteht immer noch,
      auch wenn man den Timer löscht und neu anlegt... hängt das alles zusammen?

    • Heute Morgen dann die nächste Runde:
      Ein Wiederholungstimer, der gestern nacht lief und dann das nächste Mal am Dienstag laufen soll:
      1. Bild nach dem Holen aus dem dem Standby.
      2. Bild nach Neustart, ohne den Timer anzufassen
      3. Bild nach manueller Korrektur der Endzeit wieder auf 6:10 Uhr
      Dateien

      • timer1.jpg

        (200,01 kB, 61 mal heruntergeladen, zuletzt: )

      • timer2.jpg

        (248,55 kB, 46 mal heruntergeladen, zuletzt: )

      • timer3.jpg

        (247,6 kB, 38 mal heruntergeladen, zuletzt: )

    • Die nächsten beschädigten Timer

      Die nächsten beschädigten Timer sind die, die als Wiederholungstimer in der Nacht von Freitag 27.03.2015 auf Samstag 28.03.2015 liefen und danach automatisch auf den 03.04.2015 gesetzt wurden. (siehe Bild)
      Nummer 1 "Castle +" ist in Ordnung (03.04.2015 20:05 - 04.04.2015 04:00)
      Nummer 2 "Sons of Anarchy" läuft plötzlich über einen Tag lang vom 03.04.2015 21:30 bis zum 05.04.2015 statt bis zum 04.04.2015 02:30
      Nummer 3 "House of Cards" läuft rückwärts vom 04.04.2015 02:50 bis zum 03.04.2015 06:10

      Nach einem Neustart der Vu+ Duo² wird Nummer 3 dann 0 Minuten lang vom 04.04.2015 02:50 bis 04.04.2015 02:50 gehen.

      Alle beschädigten Timer scheinen etwas mit einer Zeit zwichen 02:00 und 03:00 nachts zu tun zu haben.
      Deswegen die Vermutung, dass die Berücksichtigung der Zeitumstellung hier irgendetwas übertreibt.

      (Screenshot Fehlbedienung, aber man kann alles erkennen)
      Dateien

      • timer4.png

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

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

    • ... mag sein, dass ich der Einzige bin, bei dem das auftritt.

      Falls doch nicht und Ihr überprüft Eure Timer für nächste Woche nicht, werden wohl so einige Aufnahmen defekt sein.

    • Du hast da aber keine (Wiederholungs-)Timer drin, deren Anfangs- oder Endzeit in den Zeitraum von 02:00 bis 03:00 Uhr fallen.

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

    • Gut. Dann möchte ich bitte nur wissen, was ich falsch mache. (VTI 8.0)
      Die Zeitumstellung im letzten Oktober mit VTI 7 hatte übrigens keine Probleme gemacht.

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

    • @Schomi:
      Wie meinst Du das? Wenn der Timer sagt, dass er jetzt 1740 Minuten laufen wird statt 300 Minuten, inklusive passender Zeitangaben,
      soll das von der Maschine gelogen sein und sie nur 300 Minuten aufnehmen?

    • Aha, und wann würde sie ihre Lüge kundtun?
      Sowohl Webif als auch OSD sind sich einig, dass 1740 Minuten aufgenommen werden.

      Überlegung:
      Der Timer geht von 21:30 bis 02:30 am nächsten Morgen.
      Die automatische wöchentliche Verschiebung des Wiederholungstimers verlegt den Timer nach dem jetzigen Lauf auf die nächste Woche.
      Zwischen Heute und nächster Woche findet die Umstellung auf Sommerzeit statt.
      Statt das aber nur für den entsprechenden Sonntag zu berücksichtigen, denkt sich der Programmteil, egal, welcher Wochtag, dass eine Endzeit 02:30 zwischen 02:00 und 03:00 nicht existiert, da ja um 02:00 auf 03:00 umgestellt wird. Deshalb wird das Ende auf die nächste existierende 02:30, also einen Tag später, verschoben.

      Wenn ich die Timer korrigiere, stimmt wieder alles (was war dann die "Lüge"?)

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

    • Auszug aus der timer.py:

      Quellcode

      1. def addOneDay(self, timedatestruct):
      2. oldHour = timedatestruct.tm_hour
      3. newdate = (datetime.datetime(timedatestruct.tm_year, timedatestruct.tm_mon, timedatestruct.tm_mday, timedatestruct.tm_hour, timedatestruct.tm_min, timedatestruct.tm_sec) + datetime.timedelta(days=1)).timetuple()
      4. if localtime(mktime(newdate)).tm_hour != oldHour:
      5. 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()
      6. return newdate

      Wenn in "processRepeated" die nächste Laufzeit für einen Wiederholungstimer berrechnet werden soll, wird per addOneDay so oft ein Tag zu den Anfangs- und Endzeiten (verarbeitet wird mit Lokalzeit, nicht UTC) dazuaddiert,
      bis der nächste Wiederholungstag erreicht ist.
      Wenn, wegen der Lokalzeit über den Zeitumstellungssonntag hinaus addiert wird, wird beim Überschreiten des Zeitumstellungssonntags, da ja aus 02:30 eine 03:30 werden, statt einem Tag zwei Tage addiert.
      Da immer mit dem Additionergebnis weitergearbeitet wird, aber nur der Start darauf überprüft, ob der Zieltag erreicht wurde, bleibt auch, wenn der Timer erst am Freitag nach der Zeitumstellung laufen soll, der zusätzlich addierte Tag der Endzeit erhalten.
      Die Maschine lügt also doch nicht, sie ändert den Timer wirklich von 300 Minuten auf eine Laufzeit von 1740 Minuten (1 Tag + 300 Minuten).

      Quellcode

      1. # update self.begin and self.end according to the self.repeated-flags
      2. def processRepeated(self, findRunningEvent = True):
      3. print "ProcessRepeated"
      4. if (self.repeated != 0):
      5. now = int(time()) + 1
      7. #to avoid problems with daylight saving, we need to calculate with localtime, in struct_time representation
      8. localrepeatedbegindate = localtime(self.repeatedbegindate)
      9. localbegin = localtime(self.begin)
      10. localend = localtime(self.end)
      11. localnow = localtime(now)
      13. print "localrepeatedbegindate:", strftime("%c", localrepeatedbegindate)
      14. print "localbegin:", strftime("%c", localbegin)
      15. print "localend:", strftime("%c", localend)
      16. print "localnow:", strftime("%c", localnow)
      18. day = []
      19. flags = self.repeated
      20. for x in (0, 1, 2, 3, 4, 5, 6):
      21. if (flags & 1 == 1):
      22. day.append(0)
      23. print "Day: " + str(x)
      24. else:
      25. day.append(1)
      26. flags = flags >> 1
      28. # if day is NOT in the list of repeated days
      29. # OR if the day IS in the list of the repeated days, check, if event is currently running... then if findRunningEvent is false, go to the next event
      30. while ((day[localbegin.tm_wday] != 0) or (mktime(localrepeatedbegindate) > mktime(localbegin)) or
      31. ((day[localbegin.tm_wday] == 0) and ((findRunningEvent and localend < localnow) or ((not findRunningEvent) and localbegin < localnow)))):
      32. localbegin = self.addOneDay(localbegin)
      33. localend = self.addOneDay(localend)
      34. print "localbegin after addOneDay:", strftime("%c", localbegin)
      35. print "localend after addOneDay:", strftime("%c", localend)
      37. #we now have a struct_time representation of begin and end in localtime, but we have to calculate back to (gmt) seconds since epoch
      38. self.begin = int(mktime(localbegin))
      39. self.end = int(mktime(localend))
      40. if self.begin == self.end:
      41. self.end += 1
      43. print "ProcessRepeated result"
      44. print strftime("%c", localtime(self.begin))
      45. print strftime("%c", localtime(self.end))
      47. self.timeChanged()
      Alles anzeigen

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

    • Das lief ab, als mein "Sons of Anarchy"-Wiederholungstimer am Samstag 28.03.2015 früh erneuert werden sollte:
      Durch die Sommerzeit war die Stunde bei der Endzeit nach der Addition anders als vorher, wodurch 2 Tage statt nur 1 Tag addiert wurden, was sich dann bis zum Ende durchschleppte.

      Quellcode

      1. timer1 = Timer(Jeden Fr 21:30 Lokalzeit bis Sa 02:30 Lokalzeit) letzter Lauf 2015-03-27, Timerstart = 2015-03-20
      2. Nach Ablauf des jetzigen Durchlaufs:
      3. processRepeated(timer1, findRunningEvent = True)
      4. ...
      5. now = Jetzt + 1 Sekunde in UTC
      6. localrepeatedbegindate = 2015-03-20 (oder früher)
      7. localbegin = 2015-03-27 21:30
      8. localend = 2015-03-28 02:30
      9. localnow = 2015-03-28 02:32
      10. day = []
      11. flags = 0010000 (So-Sa-Fr-Do-Mi-Di-Mo) Mo=0, So=6
      12. ...
      13. day = [1,1,1,1,0,1,1]
      14. while
      15. Durchlauf 1 Fr
      16. ( ( day[Fr] != 0 ) or ( 2015-03-20 > 2013-03-27 ) or
      17. FALSCH FALSCH
      18. ( ( day[Fr] == 0 ) and ( ( findRunningEvent and 2015-03-28 02:30 < 2015-03-28 02:32 ) or ( ( not findRunningEvent ) and 2015-03-27 21:30 < 2015-03-28 02:32 ) ) ) )
      19. WAHR WAHR WAHR FALSCH WAHR
      20. => WAHR
      21. localbegin = addOneDay (localbegin)
      22. => oldHour = 21
      23. newdate = 2015-03-27 21:30 + 1 Tag = 2015-03-28 21:30
      24. if 21 != 21 return (2015-03-27 21:30 + 2 Tage = 2015-03-29 21:30) trifft nicht zu!
      25. return 2015-03-28 21:30 trifft zu!
      26. localbegin = 2015-03-28 21:30
      27. localend = addOneDay (localend)
      28. => oldHour = 02
      29. newdate = 2015-03-28 02:30 + 1 Tag = 2015-03-29 03:30 (wegen Sommerzeitumstellung)
      30. if 03 != 02 return (2015-03-28 02:30 + 2 Tage = 2015-03-30 02:30) trifft zu!
      31. return 2015-03-29 03:30 trifft nicht zu!
      32. localend = 2015-03-30 02:30
      33. Durchlauf 2 Sa
      34. ( ( day[Sa] != 0 ) or ( 2015-03-20 > 2013-03-28 ) or
      35. WAHR FALSCH
      36. ( ( day[Sa] == 0 ) and ( ( findRunningEvent and 2015-03-30 02:30 < 2015-03-28 02:32 ) or ( ( not findRunningEvent ) and 2015-03-28 21:30 < 2015-03-28 02:32 ) ) ) )
      37. FALSCH WAHR FALSCH FALSCH FALSCH
      38. => WAHR
      39. localbegin = addOneDay (localbegin)
      40. => oldHour = 21
      41. newdate = 2015-03-28 21:30 + 1 Tag = 2015-03-29 21:30
      42. if 21 != 21 return (2015-03-28 21:30 + 2 Tage = 2015-03-30 21:30) trifft nicht zu!
      43. return 2015-03-29 21:30 trifft zu!
      44. localbegin = 2015-03-29 21:30
      45. localend = addOneDay (localend)
      46. => oldHour = 02
      47. newdate = 2015-03-30 02:30 + 1 Tag = 2015-03-31 02:30
      48. if 02 != 02 return (2015-03-30 02:30 + 2 Tage = 2015-04-01 02:30) trifft nicht zu!
      49. return 2015-03-31 03:30 trifft zu!
      50. localend = 2015-03-31 02:30
      51. Durchlauf 3 So
      52. localbegin = addOneDay (localbegin) = 2015-03-30 21:30
      53. localend = addOneDay (localend) = 2015-04-01 02:30
      54. Durchlauf 4 Mo
      55. localbegin = addOneDay (localbegin) = 2015-03-31 21:30
      56. localend = addOneDay (localend) = 2015-04-02 02:30
      57. Durchlauf 5 Di
      58. localbegin = addOneDay (localbegin) = 2015-04-01 21:30
      59. localend = addOneDay (localend) = 2015-04-03 02:30
      60. Durchlauf 6 Mi
      61. localbegin = addOneDay (localbegin) = 2015-04-02 21:30
      62. localend = addOneDay (localend) = 2015-04-04 02:30
      63. Durchlauf 7 Do
      64. localbegin = addOneDay (localbegin) = 2015-04-03 21:30
      65. localend = addOneDay (localend) = 2015-04-05 02:30
      66. Durchlauf 8 Fr
      67. ( ( day[Fr] != 0 ) or ( 2015-03-20 > 2013-04-03 ) or
      68. FALSCH FALSCH
      69. ( ( day[Fr] == 0 ) and ( ( findRunningEvent and 2015-04-05 02:30 < 2015-03-28 02:32 ) or ( ( not findRunningEvent ) and 2015-04-03 21:30 < 2015-03-28 02:32 ) ) ) )
      70. WAHR WAHR FALSCH FALSCH FALSCH
      71. => FALSCH, Schleifenende
      72. self.begin = 2015-04-03 21:30 umgewandelt nach UTC
      73. self.end = 2015-04-05 02:30 umgewandelt nach UTC
      74. ...
      75. self.timeChanged()
      Alles anzeigen

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

    • Aus dem gleichen Grund hatte auch bei meinem "House of Cards"-Timer die Startzeit die Endzeit überholt.
      Was genau hatte sich der Programmierer bei der Addition von 2 Tagen wegen unterschiedlichem Stundenergebnis gedacht?

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