Dbus2vdr vergibt andere IDs als svdrpsend

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.

Zitat von mini73

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.

Ja, stimmt für die Recordings. Das Problem mit den Timer-Events etc. bleibt allerdings leider dennoch bestehen. Wenn Klaus allerdings dagegen ist wird es wohl schon gute Gründe für das festhalten geben.

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.

Ah, OK. Danke!