Remotetimers prüft vor jeder Änderung mit "LSTT timer-nummer" ob sich der betroffene Timer seit der letzten Änderung in irgendeiner Weise verändert hat (wobei das "recording"-Flag ignoriert wird). Falls ja, wird die Aktion abgebrochen und die Timer-Liste neu geladen. Das greift insbesondere auch dann, wenn sich die Timer-Nummern verschoben haben. Denn dann wird mir "LSTT veraltete-timer-nummer" einen ganz anderen Timer liefern, also Abbruch. Hatte bisher keine Klagen mit dieser Vorgehensweise.
Fortlaufende Timer-IDs stellen sicher, dass ein Timer nach Abruf der Timer-Liste später wieder gefunden wird. Aber solange SVDRP keine parallelen Verbindungen unterstützt, sollte jede Anwendung den SVDRP-Port schleunigst wieder freigeben. Vor jeder erneuten Operation müsste also geprüft werden, ob VDR seitdem neu gestartet wurde. Wenn ja, muss auch wieder abgebrochen werden. Dagegen helfen nur UUIDs oder das Abspeichern der eindeutigen Timer-ID. Die zuletzt vergebene ID in der Config zu speichern, halte ich wie Klaus für ungeeignet. Ich würde die neuen IDs in der timers.conf abspeichern und bei den SVDRP-Befehlen über ein Flag steuern, ob die eindeutige ID statt der fortlaufenden Nummer ausgegeben werden soll. Damit bliebe die Rückwärtskompatibilität erhalten.
Wenn es um die Bearbeitung von Timern durch ein externes Programm geht, sehe ich bis hierher jedoch keinen großen Vorteil in der Einführung von IDs. Auch bei einer langlebigen ID (egal ob in der Form wie es Klaus vorschwebt oder in Form einer UUID) muss die in Remotetimers durchgeführte Überprüfung stattfinden. Denn nichts ist ärgerlicher als wenn Benutzer/Anwendung A einen Timer ändert und Benutzer/Anwendung B diese Änderung 1 Minute später einfach Rückgängig macht, weil die Änderung auf einem älteren Stand basiert. Wesentlich kritischer ist zu sehen, dass SVDRP keine Garantie gibt, dass sich z.B. zwischen unmittelbar aufeinanderfolgenden LSTT- und MODT-Befehlen der Timer nicht ändert. Wenn dies so bleibt, kann letzlich nur der komplette Timer-String als ID fungieren und z.B. MODT müsste als Argument den alten und den neuen String übergeben bekommen, DELT den alten String. Und VDR intern müsste der passende Timer über genau diesen String gesucht werden (wobei einzelne Werte wie das "recording" flag ignoriert werden müssten). Eine eindeutige ID ist also eigentlich gar nicht so wichtig. Die Möglichkeit einen Timer atomar ändern zu können ist eigentlich das Entscheidende.
Zu den IDs für Aufnahmen: Wenn nicht mit UUID, dann wäre eine schöne eindeutige ID die Kombination von den struct stat Feldern st_dev und st_ino
