[ANNOUNCE] VDR developer version 1.7.36

Zitat von kls

Ist dabei auch Device-Bonding im Spiel?

Klaus

wenn ich es richtig verstehe, betrifft device bonding nur Sat-TV?
Ich habe Kabel, ganz normale DVB-C-Karten.

Zitat von kls

Dafür bräuchte ich ein OK von Udo Richter ("Urig"), denn der hat den Shutdown-Handler eingebaut und müsste beurteilen können, ob das so geht.

Prinzipiell ok, ich würde den speziellen Wert activeTimeout = 1 aber auf den konkreten Fall des VDR-Starts beschränken, damit auch weiterhin die Information, seit wann kein User mehr aktiv ist, erhalten bleibt. Das kommt z.B. immer dann vor, wenn ein Shutdown abgebrochen wurde.

Aufgehübschte Version des Patch ist im Anhang. Nicht wirklich getestet, aber überschaubar, sollte gehen.

Probleme mit springenden Uhren dürfte es übrigens noch einige in VDR geben, so löst ein mehrminütiger Sprung während einer Aufnahme IMHO immer noch einen "Video Data Stream Broken" aus.

Gruß,

Udo

Zitat von Urig

Prinzipiell ok, ich würde den speziellen Wert activeTimeout = 1 aber auf den konkreten Fall des VDR-Starts beschränken, damit auch weiterhin die Information, seit wann kein User mehr aktiv ist, erhalten bleibt. Das kommt z.B. immer dann vor, wenn ein Shutdown abgebrochen wurde.

Aufgehübschte Version des Patch ist im Anhang. Nicht wirklich getestet, aber überschaubar, sollte gehen.

Wow, das wird noch richtige "rocket science"

Zitat

+ ///< Set the time in the future when VDR will switch into non-interactive mode or power down.
+ ///< Seconds >= 0 means as many seconds in the future.
+ ///< Seconds = -1 means Setup.MinUserInactivity in the future.
+ ///< Seconds = -2 means never.
+ ///< Seconds = -3 means a long, unknown time ago.

Alles anzeigen

Hmmmm.... "Vor langer, langer Zeit wird einmal gewesen sein werden..."

Zitat

+ ///< Setup.MinUserInactivity = 0 will overrule this, unless Force = true is given.
+ ///< If Setup.MinUserInactivity = 0 and Force = false, Seconds is ignored and VDR will
+ ///< stay interactive forever (like Seconds = -2).

Nur gut, saß ich dieses Feature selber nicht brauche - verstehen würde ich es vermutlich auf Anhieb nicht...

Zitat

Probleme mit springenden Uhren dürfte es übrigens noch einige in VDR geben, so löst ein mehrminütiger Sprung während einer Aufnahme IMHO immer noch einen "Video Data Stream Broken" aus.

Ein System, auf dem ein "mehrminütiger Sprung" passiert, hat aber vermutlich auch noch ganz andere Probleme

Klaus

Zitat von kls

Ein System, auf dem ein "mehrminütiger Sprung" passiert, hat aber vermutlich auch noch ganz andere Probleme

Es genügt doch schon wenn es sich in der EU befindet, dann darf es das ganze 2x im Jahr mitmachen (zumindest hatte ich die Threads von der letzten Zeitumstellung so in Erinnerung)

Zitat von seahawk1986

Es genügt doch schon wenn es sich in der EU befindet, dann darf es das ganze 2x im Jahr mitmachen (zumindest hatte ich die Threads von der letzten Zeitumstellung so in Erinnerung)

Das verstehe ich bis heute noch nicht... die Zeit springt ja überhaupt nicht beim Wechsel Sommerzeit<->Winterzeit, nur die Darstellung in der OSD Anzeige ändert sich. Warum das also Einfluß auf die Funktion im VDR hat...?

Also Sommerzeit<->Winterzeitwechsel und falschgehende Transponderuhren sollten eigentlich unterschiedliche Probleme sein.

cu

Wenn die Systemuhr im VDR auf UTC gestellt ist, dann kommt es bei der Zeitumstellung an keiner Stelle zu Problemen. Unix-Systeme arbeiten intern üblicherweise komplett mit UTC und verlassen sich darauf, dass diese Zeit niemals springt. Mit ein Grund warum der VDR mittlerweile auch die Zeit nachführt und nurnoch springt wenn die Differenz zu groß wird.

Zitat von Mreimer

Wenn die Systemuhr im VDR auf UTC gestellt ist, dann kommt es bei der Zeitumstellung an keiner Stelle zu Problemen.

Einspruch. Bei der letzten Zeitumstellung haben sich wieder Bugs (die zu kaputten Aufnahmen führten) gezeigt. Nur ist es natürlich schwer das ganze zu debuggen um die schuldigen Stellen zu finden.

cu

Zitat von Keine_Ahnung

Bei der letzten Zeitumstellung haben sich wieder Bugs (die zu kaputten Aufnahmen führten) gezeigt. Nur ist es natürlich schwer das ganze zu debuggen um die schuldigen Stellen zu finden.

In der Nacht der Zeitumstellung muß man halt etwas aufpassen, wenn man einen Timer programmmiert, der über die problematische Zeit hinweggeht. Da muß man halt dann die fehlende oder doppelte Stunde mit einkalkulieren.

Klaus

Hmm, aber bei UTC gäbe es ja keine Umstellung. Wenn der VDR intern mit UTC rechnen würde und nur die Anzeige bzw. Ausgabe in der lokalen Zeit(-zone) machen würde, gäbs doch ansich kein Problem. Oder sehe ich das falsch?

Zitat von kls

In der Nacht der Zeitumstellung muß man halt etwas aufpassen, wenn man einen Timer programmmiert, der über die problematische Zeit hinweggeht. Da muß man halt dann die fehlende oder doppelte Stunde mit einkalkulieren.

Der Witz ist ja das weder eine Stunde fehlt noch das eine hinzukommt. Das ist ja wirklich nur ne Sache der Darstellung der Zeit im OSD.

Aber beim nächsten Wechsel werde ich mal versuchen etwas Logging einzubauen und bewusst einige problematische Timer zu programieren.

cu

Zitat von TheChief

Hmm, aber bei UTC gäbe es ja keine Umstellung. Wenn der VDR intern mit UTC rechnen würde und nur die Anzeige bzw. Ausgabe in der lokalen Zeit(-zone) machen würde, gäbs doch ansich kein Problem. Oder sehe ich das falsch?

Die Start- und Stopzeiten der Timer werden als *Tageszeiten* in 24-Stunden-Zeit gespeichert. Sonst könnte man ja keinen wiederholenden Timer programmieren.

Klaus

Zitat von kls

Die Start- und Stopzeiten der Timer werden als *Tageszeiten* in 24-Stunden-Zeit gespeichert. Sonst könnte man ja keinen wiederholenden Timer programmieren.

Klaus

Verstehen tu ich das zwar jetzt nicht, aber Du bist der große Meister! Was verstehst Du denn unter wiederholenden Timern? Und wieso kann man die in UTC nicht programmieren?

Zitat von TheChief

Verstehen tu ich das zwar jetzt nicht, aber Du bist der große Meister! Was verstehst Du denn unter wiederholenden Timern? Und wieso kann man die in UTC nicht programmieren?

Sowas zum Beispiel:

1:S28.2E-2-2042-8305:MTWTFSS:1858:1935:99:99:Serien~The Big Bang Theory:

Das ist ein täglicher Timer von 18:58 Uhr bis 19:35 Uhr.
Ich sehe nicht, wie man das in UTC angeben sollte.

Klaus

Zitat von TheChief

Und wieso kann man die in UTC nicht programmieren?

Kann man schon, aber das könnte komplexer werden als das jetzige Format - ein Beispiel wie man sowas mit UTC Zeiten lösen kann wäre die RRULE des iCalendar-Formats: http://www.kanzaki.com/docs/ical/recur.html

Bei täglichen Timern müsste man dann natürlich die Zeiten anpassen, nachdem eine Aunahme lief.

Vielleicht so:

1:S28.2E-2-2042-8305:MTWTFSS:Startzeit in UTC:Länge der Aufnahme in Sekunden:99:99:Serien~The Big Bang Theory:

Nachdem die Aufnahme am Montag lief, Startzeit auf Dienstag anpassen.

Aber war nur ein Gedanke - so müssten ja auch sämtliche Plugins geändert werden. Ich hoffe ja, dass Sommer/Winterzeit irgendwann abgeschafft wird.

Zumindest könnte man anstatt der Endzeit der Aufnahme einfach die Länge angeben und Länge anhand der index Datei oder ähnlich prüfen.

Oder Endzeit-Startzeit in Sekunden mit Länge der bisherigen Aufnahme prüfen....Ideen hab ich viele.

Zitat von TheChief

Bei täglichen Timern müsste man dann natürlich die Zeiten anpassen, nachdem eine Aunahme lief.

Vielleicht so:

Code

1:S28.2E-2-2042-8305:MTWTFSS:Startzeit in UTC:Länge der Aufnahme in Sekunden:99:99:Serien~The Big Bang Theory:

Nachdem die Aufnahme am Montag lief, Startzeit auf Dienstag anpassen.

Aber war nur ein Gedanke - so müssten ja auch sämtliche Plugins geändert werden. Ich hoffe ja, dass Sommer/Winterzeit irgendwann abgeschafft wird.

Zumindest könnte man anstatt der Endzeit der Aufnahme einfach die Länge angeben und Länge anhand der index Datei oder ähnlich prüfen.

Alles anzeigen

Alles viel zu kompliziert. Anfangs- und Endzeit ist genau das, was der Benutzer kennt. Wenn er erst die Länge ausrechnen muß, dann passieren da garantiert wieder Fehler.
Das jetzige Format ist einfach und klar. Daß es bei der Zeitumstellung immer mal zu Problemen kommen kann, damit muß man halt leben (passiert ja auch in anderen Bereichen, nicht nur bei VDR).
Und gegen eine Abschaffung der Zeitumstellung (dann aber bitte immer "Sommerzeit") hätte ich freilich auch nichts ;-).

Klaus

Nicht der Benutzer berechnet die Länge, sondern der VDR.

Irgend so etwas wie:

While (Endzeit - Startzeit <= Länge der Aufnahme)
{
//Nimm auf
}

Im Moment scheint der VDR ja nur zu prüfen: Ist es 19:35? Wenn ja, dann stoppe die Aufnahme.

Was spricht dagegen die Zeiten dort einfach in UTC zu speichern? Der Nutzer gibt es weiterhin in Lokalzeit ein und es wird einfach in UTC gespeichert. Ich sehe da so spontan keine Probleme.

cu

Da war ja das Problem bei täglichen Timern. UTC ist ja fortlaufend, lässt sich schlecht speichern.

Zitat von TheChief

Da war ja das Problem bei täglichen Timern. UTC ist ja fortlaufend, lässt sich schlecht speichern.

Natürlich ist UTC forlaufend, so funktioniert das mit der Zeit, sie vergeht stetig fortlaufend

Mal nen Beispiel, will man einen täglichen Timer von 20:00 - 21:00 dann gibt man in der GUI 20:00 - 21:00 ein, gespeichert (per Vereinbarung UTC) wird dann ein täglicher Timer von 19:00 - 20:00. Wo ist das Problem?

Der VDR wird täglich 19:00 - 20:00 UTC (Also 20:00 - 21:00 Lokalzeit) aufzeichnen, egal ob gerade die Sommerzeit aktiv ist oder nicht.

cu