Verschieben sich die Timer-IDs ?

    Hallo zusammen,


    Es ist mir jetzt schon einige male passiert, dass ich im VDRADMIN auf einen "Editieren" Link geklickt habe und ich dann eine andere Sendung im Editor hatte. Oder die Timer-Liste durchgegangen bin, einige markiert habe und die dann alle deaktivieren wollte, aber danach waren andere deaktiviert (zum Glück lösche ich nie, sondern deaktiviere immer nur).


    Ich habe den Verdacht, dass sich die Timer-IDs verschieben, wenn zwischen dem Darstellen der Timer-Seite und dem Klick auf einen Link oder Button ein Timer aus der Liste rausfliegt (z.B. weil er abgelaufen ist). Ich denke auch, das liegt nicht am VDRADMIN, weil der die Timer-IDs ja auch vom VDR bekommt und die dann weiterbenutzt.


    Das ist natürlich sehr unpraktisch, denn nach Murphy läuft immer dann ein Timer aus, wenn man gerade die Liste bearbeitet und dafür länger braucht. Manchmal denke ich dran, dass ich vor einer solchen Aktion erst mal checke, ob es demnächst soweit ist. Aber oft merke ich es erst, wenn es zu spät ist.


    Letztendlich sollte der VDR meiner Meinung nach mit festen ID's arbeiten (vielleicht eignet sich da die Sendugs-Nummer ?). Hat jemand für die Zwischenzeit einen Trick auf Lager ?

    Also, ich hab's gerade nachgeprüft. Die verschieben sich definitiv.


    Ich bin auf die Timer-Übersicht gegangen, diese nach Datum/Uhrzeit sortiert angezeigt und habe mir die ersten paar ID's gemerkt. Dann habe ich die Seite im Browser so stehenlassen bis ein Timer abgelaufen ist und sie dann neu geladen. Alle Timer, deren ID's ich mir gemerkt hatte, hatten danach andere ID's.


    Mal ehrlich, es ist nicht der Zweck einer ID, dass sie nur für einen begrenzten Zeitraum gültig ist.


    Man hat ja die Timer-Liste nicht immer nach Datum/Uhrzeit sortiert und sieht daher nicht gleich, ob demnächst ein Timer abläuft. Und in einem Mehrpersonen-Haushalt, in dem jeder per VDRADMIN Timer hinzufügen kann, wird es noch unvorhersehbarer.


    Ich denke, das Live-Plugin müsste auch betroffen sein.

    Genau genommen sind das auch keine "IDs", sondern die Timer sind einfach durchnummeriert, beginnend bei 1. Wenn ein Timer gelöscht wird, dann verschieben sich deswegen alle nachfolgenden Timer-Nummern um 1.
    Ich habe vor, das zu ändern und in einer laufenden VDR-Instanz jedem Timer eine immer eindeutige Nummer zu geben (die dann auch guten Gewissens "ID" heißen darf) indem ein globaler Zähler bei jedem neu angelegten Timer hochgezählt wird. Das hat natürlich zur Folge, daß irgendwann (wenn VDR immer läuft) die Timer-"Nummern" auch sehr hohe Werte annehmen können.
    Ähnliches gilt übrigens auch für Aufnahmen.
    Da das aber eine inkompatible Änderung ist (womöglich verlässt sich das eine oder andere Tool darauf, daß die Nummern bei 1 beginnen und fortlaufend sind) kann ich das nicht mehr vor der Version 2.0 machen. Danach aber dann sehr bald.


    Klaus

    Zitat von kls

    Ich habe vor, das zu ändern und in einer laufenden VDR-Instanz jedem Timer eine immer eindeutige Nummer zu geben (die dann auch guten Gewissens "ID" heißen darf) indem ein globaler Zähler bei jedem neu angelegten Timer hochgezählt wird. Das hat natürlich zur Folge, daß irgendwann (wenn VDR immer läuft) die Timer-"Nummern" auch sehr hohe Werte annehmen können.
    Ähnliches gilt übrigens auch für Aufnahmen.


    Cool, wäre toll wenn die LAN-Weit eindeutig wären ;). Wie basteln da gerade ans etwas herum.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Moin!


    LAN-weit muss nicht zwingend. Ein externer Service kann die Liste mit Hostnamen und Host-Timer-ID herstellen, dass muss der vdr (noch) nicht können. Das geht bestimmt auch per Plugin.
    Ein bisschen gezuckert mit avahi4vdr und dbus2vdr kann ich mir da was nettes vorstellen... :)


    Und für die Aufnahmen wünsche ich mir das auch: ein neues Feld in der info-Datei mit einer UUID für die Aufnahme, die sich nie ändert, jeder Schnitt bekommt auch eine neue UUID.
    Wenn eine Aufnahme ohne aufgemacht wird, wird sie einfach einmalig erzeugt und gut ist. Da schreibt man dann ein Script für, dass jagt man einmal über alle Aufnahmen.


    Fühlt sich an wie Weihnachten... :) Aber erst mal die 2.0, damit man wieder in Ruhe entwickeln kann. :)


    Lars.

    Man könnte die ja in einer Datenbank speichern, dann wäre eine gelöschte ID wieder frei, wäre eindeutig und würde keine hohen Werte erreichen.


    Andy

    Moin!


    Nein, IDs sollten nicht wiederverwendet werden, weil dann externe Programme "kaputt" gehen, weil falsche Informationen miteinander verknüpft werden.
    Ich bin nicht für eine laufende Nummer, sondern für eine UUID (mal so als Vorschlag).


    Lars.

    Zitat von mini73

    Moin!


    LAN-weit muss nicht zwingend. Ein externer Service kann die Liste mit Hostnamen und Host-Timer-ID herstellen, dass muss der vdr (noch) nicht können. Das geht bestimmt auch per Plugin.
    Ein bisschen gezuckert mit avahi4vdr und dbus2vdr kann ich mir da was nettes vorstellen... :)


    Und für die Aufnahmen wünsche ich mir das auch: ein neues Feld in der info-Datei mit einer UUID für die Aufnahme, die sich nie ändert, jeder Schnitt bekommt auch eine neue UUID.
    Wenn eine Aufnahme ohne aufgemacht wird, wird sie einfach einmalig erzeugt und gut ist. Da schreibt man dann ein Script für, dass jagt man einmal über alle Aufnahmen.


    Das ganz bestimmt nicht!


    Klaus

    Zitat von kls

    Es wird eine laufende Nummer sein, die innerhalb einer laufenden VDR-Instanz hochgezählt wird.
    Wird der VDR neu gestartet, fängt es wieder bei 1 an.

    Hm, mit Verlaub, dann kannst Du Dir die Arbeit aber auch fast sparen. Denn das verschiebt das Problem externer Programme, die mit den IDs arbeiten, nur. Die wissen ja gegebenenfalls nicht, dass der VDR neu gestartet wurde und fallen dann wieder darauf rein. Gerade HTTP basierte Dienste sind für sowas anfällig, da eine Seite im Browser ja schon lange stehen kann und in der Zwischenzeit alles mögliche passieren kann.


    Entweder man macht eine wirkliche ID, d.h. die Numer IDentifiziert einen Timer/Aufnahme eindeutig, oder man beläßt es einfach bei der fortlaufenden Nummerierung. Alles dazwischen ist nicht Fisch und nicht Fleisch.


    Nur meine 0,02€, aber wenn Du Dir die Arbeit schon machst, würde ich es richtig machen. Du musst Dir die ID ja nur irgendwo merken oder gegebenenfalls beim Start die höchste zuletzt vergebene suchen. Über ein "Überlaufen" würde ich mir da mal keine Gedanken machen, ein 32bit Integer erfasst >4 Millarden Werte (bzw. >2 Millarden wenn das Vorzeichen ein Problem ist). Wer jemals soviele Timer oder Aufnahmen in seinem Leben anlegt, hat eventuell noch ganz andere Probleme :D

    Zitat von weinleiche

    Hm, mit Verlaub, dann kannst Du Dir die Arbeit aber auch fast sparen. Denn das verschiebt das Problem externer Programme, die mit den IDs arbeiten, nur. Die wissen ja gegebenenfalls nicht, dass der VDR neu gestartet wurde und fallen dann wieder darauf rein.


    SVDRP könnte ja einen Timestamp übermitteln, seit dem dieser VDR läuft. Ändert sich dieser zwischen zwei Aufrufen, dann weiß der Aufrufer, daß er sich eventuelle Listen neu holen muß.


    Zitat


    Entweder man macht eine wirkliche ID, d.h. die Numer IDentifiziert einen Timer/Aufnahme eindeutig, oder man beläßt es einfach bei der fortlaufenden Nummerierung. Alles dazwischen ist nicht Fisch und nicht Fleisch.


    Nur meine 0,02€, aber wenn Du Dir die Arbeit schon machst, würde ich es richtig machen. Du musst Dir die ID ja nur irgendwo merken oder gegebenenfalls beim Start die höchste zuletzt vergebene suchen. Über ein "Überlaufen" würde ich mir da mal keine Gedanken machen, ein 32bit Integer erfasst >4 Millarden Werte (bzw. >2 Millarden wenn das Vorzeichen ein Problem ist). Wer jemals soviele Timer oder Aufnahmen in seinem Leben anlegt, hat eventuell noch ganz andere Probleme :D


    Na gut, die jeweils zuletzt vergebene ID kann ich mir ja in setup.conf merken. Sollte allerdings etwas passieren, so daß der VDR diese Daten nicht mehr abspeichern kann, dann haben die Timer bzw. Aufnahmen nach einem Neustart auch IDs, die unter Umständen völlig falsch sind (und ein Client wird das nicht wissen). Da halte ich es fast für sinnvoller, klipp und klar zu sagen, daß ein Client bei einem SVDRP-Verbindungsaufbau, bei dem er sich auf IDs einer Liste beziehen möchte, die er von einer älteren Verbindung bekommen hat, vergewissern muß, daß die VDR-Instanz seitdem ununterbrochen gelaufen ist.


    Klaus

    Für Timer ist für mich die Methode "bei jedem Start mit 1 anfangen" ausreichend.


    Eine eindeutige ID für jede Aufnahme würde mir nichts nützen, da ich z.B.
    auch mal ne USB Platte mit VDR Aufnahmen von einem Freund anstecke
    und dann hätten man eh doppelte IDs

    vdr 1.7.23 suse 12.1 64 Bit 1xTTS2-6400 HD-USB: 24TB
    vdr 1.7.23 suse 11.3 64 Bit 1xTTS2-6400, 1xTTS2-3200 + ci HD:2TB
    vdr 2.2.0 Raspberry pi HD-USB: 2TB (Garten)

    Einfach so einfach wie möglich. Und bei allzu festen Werten, die ständig hochgezählt werden, gibt es nunmal immer das theoretische Risiko irgendwann an eine technische Grenze zu fahren. Also besser bei jedem Start mit 1 beginnen.

    Stimmt, bei den Aufnahmen ist das so gesehen natürlich wirklich unütz.


    Die Methode mit dem Zeitstempel im SVDRP würde gehen.
    Vorteile:

    • Weniger Arbeit für Klaus :D
    • Die Clients können feststellen, ob ihre IDs noch gültig sind


    Nachteile:

    • Mehr Arbeit für die Cliententwickler :D
    • dadurch mehr Fehlerpotential und alte nicht (mehr) gepflegte Clients würden davon nicht profitieren


    Was genau spricht eigentlich gegen die Verwendung einer UUID? Diese hat den Vorteil, dass der vdr sich gar nichts merken muss, er generiert einfach eine neue UUID, wenn er eine neue ID für einen Timer oder eine Aufnahme benötigt.
    Ist es die Größe der UUID? Sollte heutzutage kein entscheidendes Kriterium mehr sein.
    Oder die Befürchtung, dass viele Clients einfach nur eine Nummer als ID erwarten? Das ist natürlich nicht von der Hand zu weisen.... wäre vermutlich zu aufwendig.

    Moin!


    Zitat von weinleiche

    Oder die Befürchtung, dass viele Clients einfach nur eine Nummer als ID erwarten? Das ist natürlich nicht von der Hand zu weisen.... wäre vermutlich zu aufwendig.


    Diese Befürchtung würde es bei Aufnahmen nicht geben, da es dort noch gar keine ID gibt. Ein neues Feld in der Info-Datei mit einer UUID wäre wirklich ein Gewinn. Da gäbe es auch keine Probleme mit externen Programmen, die die info-Datei parsen o.ä., weil es einfach eine neue Zeile mit einer neuen Kennung wäre. Damit sollte ein Parser immer zurecht kommen.
    Das unbeabsichtigte Löschen eines Timers, weil die IDs sich plötzlich verschoben haben, ist nicht so schlimm (weil wiederherstellbar) wie das Löschen einer Aufnahme, die man eigentlich behalten wollte.


    Das Problem mit der ID an den Timern ist, dass sie momentan keinen Platz in der timers.conf hat. Man müsste also ein zusätzliches Feld dort einbauen. Und das bedeutet, dass alle externen Programme, die direkt die timers.conf bearbeiten (oder per NEWT einen neuen Timer anlegen), das neue Format erlernen müssen.
    Wobei: Bei NEWT muss nichts geändert werden, der vdr vergibt ja die ID. Es ändert sich also "nur" was an der Ausgabe von LSTT (zusätzliche Spalte), DELT (statt Nummer eine UUID, kein Problem, lassen sich unterscheiden), UPDT hat sich sowieso noch nie um die laufende Nummer gekümmert (sollte also auch kein Problem sein, der zu ändernde Timer ließe sich mit der neuen ID sogar leichter/zuverlässiger finden).


    Einfach die UUID des Timers hinten an die timers.conf-Zeile anhängen wird sicherlich nicht funktionieren, da nirgendwo festgelegt ist, dass externe Programme bzw. Plugins keine Doppelpunkte in den aux-Daten hinterlegen dürfen. Also muss sie weiter vorne eingefügt werden. Am sinnvollsten wäre natürlich ganz vorne...


    Ich mache jetzt hier nur Gedankenspiele, weil ich eine UUID bei den Aufnahmen und Timern wirklich interessant finde, da ich an einem vdr-Meshnetz arbeite, bei dem sich die vdr in einem LAN selbstständig um das Verteilen von Timern und Anzeige der Aufnahmen der anderen vdr kümmern. Eindeutige IDs wären da sehr hilfreich... Aber ich werde sicherlich auch nichts über's Knie brechen, wenn es die nicht geben wird, ist das leider so... :)


    Mal ein Aufruf zum Sammeln von Timer-verarbeitenden Programmen: welches sind die bekannten Verdächtigen? Eine Suche im Wiki ergab:
    autotimer, autotimeredit, epgsearch, instantimer, quicktimer, remotetimers, timersync, vdradmin, xxvautotimer


    Was wird davon ernsthaft benutzt, was wird noch gepflegt?


    Lars.


    Sorry, aber UUIDs wird es nicht geben! Weder für Timer noch für Aufnahmen.
    Es wird Nummern geben wie jetzt, die halt fortlaufend hochgezählt werden. D.h. eine Nummer wird innerhalb einer VDR-Instanz immer nur einmal verwendet. Und es wird eine Möglichkeit geben zu erkennen, ob der betreffende VDR seit der letzten SVDRP-Verbindung neu gestartet wurde (Timestamp des VDR-Starts). Damit kann ein Client erkennen, ob die Nummern noch gültig sind, die er sich evtl. in einer vorhergegangenen SVDRP-Session geholt hat.
    Dadurch sollte das Format weitgehend rückwärtskompatibel sein.


    Klaus

    Zitat von mini73

    Mal ein Aufruf zum Sammeln von Timer-verarbeitenden Programmen


    Das LazyBones-Plugin für den TV-Browser: http://www.hampelratte.org/blog/?page_id=6

    Zitat von Mreimer

    Eine UUID als führender Index hat den großen Nachteil, dass sie im Vergleich mit einer einfachen Nummer relativ sperrig sind.


    Was wäre denn mit dem AUX-Feld? epgsearch verewigt sich da ja auch und ein Plugin sollte da doch auch UUIDs für jeden Timer reinschreiben können, falls noch keine drin stehen. Man könnte sich ja an die Syntax mit den Tags halten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden