Dbus2vdr vergibt andere IDs als svdrpsend

  • Hallo Community,


    die IDs zwischen Dbus2vdr und svdrpsend stimmen nicht überein




    mein Ziel war eigentlich per intelligentem Python Script die ältesten Aufnahmen im Verzeichnis /video/local/ zu finden und diese dann mit dem Befehl

    svdrpsend movr [id] ~video~archive~[Name]

    zu verschieben

    über Methoden move oder copy/del verfügt dbus2vdr nicht, soweit ich es in der Dokumentation gefunden habe.

    https://github.com/flensrocker…us2vdr/blob/master/README


    aktueller Stand Python script (ich bin kein Profi Coder ... also kann sein dass es besser geht)



    Danke für Tips und Anregungen


    Viele Grüße


    Kitsab

  • dbus2vdr hat seine eigene Liste an Aufnahmen. Die "Id" einer Aufnahme ist leider nicht das, was man bei einer Id erwartet. Richtig schön wäre es, wenn es in der Recording-Info eine uuid gäbe, die sich in der Lebenszeit der Aufnahme nie ändert und auch Neustarts des vdr überlebt.

    Man kann zwar SVDRP zum Verschieben von Aufnahmen benutzen, muss man aber nicht. Du kannst ja auch ganz normale Dateioperationen benutzen.


    Schade ist auch, dass MOVR nur die Id benutzt (die sich zwischen LSTR und MOVR ändern kann, falls der vdr zufällig neustartet). Die einzig zuverlässige Id einer Aufnahme ist ihr aktueller Pfad.

  • dbus2vdr hat seine eigene Liste an Aufnahmen. Die "Id" einer Aufnahme ist leider nicht das, was man bei einer Id erwartet. Richtig schön wäre es, wenn es in der Recording-Info eine uuid gäbe, die sich in der Lebenszeit der Aufnahme nie ändert und auch Neustarts des vdr überlebt.

    Man kann zwar SVDRP zum Verschieben von Aufnahmen benutzen, muss man aber nicht. Du kannst ja auch ganz normale Dateioperationen benutzen.


    Schade ist auch, dass MOVR nur die Id benutzt (die sich zwischen LSTR und MOVR ändern kann, falls der vdr zufällig neustartet). Die einzig zuverlässige Id einer Aufnahme ist ihr aktueller Pfad.

    Bin in der Vergangenheit auch schon über nicht eindeutige ID's gestolpert (Channels, Recordings, Timer...) - ich fände es klasse, wenn hier generell "Unique ID's" verwendet werden würden. Oder aber zumindest ein Mechanismus bei dem manuell eine Neuanordnung veranlasst werden muß. Diese Unique ID müsste ja eigentlich nicht durch den ganzen Code des VDR gezogen werden sondern "nur" generell als Zwischenschicht für alle User-Interaktionen verwendet werden. Oder liege ich da falsch? Wobei natürlich ein durchgängiges Konzept mit zusätzlicher Unique-ID vielleicht durchaus Vorteile haben könnte...

  • Da wurde schon mal drüber diskutiert und beim letzten mal wurde die Idee von Klaus verworfen.


    Intern braucht der vdr keine Id, da für jede Aufnahme, Event, Timer usw. ein Objekt im Speicher gehalten wird, welches der vdr benutzt.


    Problem ist bei einer neuen UUID aber auch, dass alte Aufnahmen usw. erst mal gar keine haben, d.h. die müssten erst mal alle eine bekommen, was dann bei readonly-Archiven ein Problem ist. Und es würde sich die Struktur der Recording-Info, der timers.conf usw. ändern, d.h. es gäbe da keine Abwärtskompatibilität.


    Ist also nicht "mal eben so".


    Machbarer wäre wohl eher, den ein oder anderen Aufnahme-SVDRP-Befehl fit zu machen, dass es mit dem Pfad umgehen kann. Das ist ja quasi eine UUID der Aufnahme, die sich eben nur ändert, wenn die umbenannt wird.

  • Die Recording-Info ließe sich leichter abwärtskompatibel ändern, da sie ja zeilenweise aufgebaut ist und man nur einen neuen Buchstaben vergeben muss. Dabei weiß ich jetzt nicht genau, ob ältere vdr-Versionen unbekannte Buchstaben ignorieren und beim Schreiben wieder in die Datei einfügen.


    Die timers.conf hat pro Zeile einen Eintrag, bei dem die Felder mit Doppelpunkt getrennt sind. Deshalb lässt sie sich nicht erweitern. Denkbar wäre, sich ein neues Format auszudenken, was ähnlich der Recording-Info ist und sich damit leichter in der Zukunft um neue Felder erweitern ließe. Das macht aber einen Wechsel zwischen vdr-Versionen schwierig. Natürlich könnte ein neuerer vdr beide Dateien schreiben, müsste beim Einlesen aber prüfen, ob die alte timers.conf neuer ist als die neue timers.xxx, falls eine ältere Version sie verändert hat.


    Dazu kommt, dass es evtl. auch externe Tools gibt, die diese Datei bearbeitet, keine Ahnung.

    Für mich wäre ein Wechsel des Dateiformats aber ok, wenn es dann z.B. einen vdr 3.x gäbe, damit klar ist, dass es keine Abwärtskompatibilität gibt. Man muss ja nicht jede Designentscheidung von vor 20 Jahren als gesetzt sehen. Ab und zu darf man sowas auch mal überdenken. :)

  • Während ein VDR läuft bleiben die IDs für Timer und Recordings konstant. Ein Client, der eine SVDRP-Verbindung aufrecht erhält, kann sich sicher sein, dass eine einmal erhaltene ID so lange gültig ist, wie die Verbindung steht. Bricht die Verbindung ab (z.B. weil der VDR neu startet), so "weiß" der Client, dass die IDs nicht mehr gültig sind. Er muss die Verbindung eh neu aufbauen und sich die Listen neu holen.

  • Hallo zusammen,


    nun habe ich mal mein Script fertig gestellt, ich stells einfach mal rein falls jemand eine Anregung braucht - bin aber kein Profi Coder :).

    Das Script wird von einem Cronjob als user vdr ausgeführt.



    Danke nochmal an die tolle Community, die einem immer mit Rat und Tat zur Seite steht.


    Viele Grüße


    Kitsab