Hallo,
bevor angefangen werden kann, RESTFulApi zu vdr-2.3.1 kompatibel zu machen, musste ich noch zwei neue Services zu Ende bauen, die gerade released wurden.
/recordings/updates und recordings/sync
Man kann nun eine Clientseitige Datenbank aufbauen und mit diesen beiden Services aktuell halten bzw. synchronisieren ohne jedes mal die komplette Liste herunterladen zu müssen (bei mir sind das bei 1950 Aufnahmen mit Scraper Daten schlappe 7.7 MB).
Ein Anwendungsbeispiel wäre die HTML5 IndexedDB.
Beim Initialen Laden der gesamten Aufnahme Liste übergibt man den neuen Parameter syncId, der einen beliebigen String übermittelt. Im Cache Verzeichnis wird eine Datei mit dieser ID als Name angelegt, die die Dateinamen der Aufnahmen und jeweils einen dazu passenden Hash enthält.
Fordert der Client nun Updates mit der selben syncId an, so wird diese Datei mit den aktuellen Aufnehmen des VDR abgeglichen und nur eine Liste der neu hinzugekommenen, gelöschten oder modifizierten Aufnahmen versendet. Das spart eine Menge Bandbreite.
Lösche ich eine Aufnahme, so kann ich die syncId ebenfalls übergeben, so das diese Aufnahme auch aus der Datei entfernt werden kann.
Bin ich der Meinung, das meine Clientseitige DB nicht mehr synchron ist, kann ich den recordings/sync Service nutzen. Dazu übermittele ich per Post ein Form Data Array mit allen Aufnahmen. Die Einträge des Arrays müssen Komma separiert den gesamten Dateinamen und den Hash der Aufnahme enthalten, den RESTFulApi jetzt mit der gesamten Aufnahme Liste bzw. den Updates liefert.
So muss das aussehen:
POST http://ip:port/recordings/sync.json?syncId=meineclientid
recordings[]=/srv/video.00/path/to/rec/timestamp.rec,abcdef0123456789&recordings[]=/srv/video.00/path/to/rec/timestamp.rec,abcdef0123456789&recordings[]=/srv/video.00/path/to/rec/timestamp.rec,abcdef0123456789In diesem Fall wird die übermittelte Liste mit den aktuelle Aufnahmen abgeglichen und widerum nur die Änderungen zurück übertragen.
In beiden Fällen wird die Sync Datei aktualisiert.
Da die Aufnahme Nummer sich jederzeit ändern kann wurde desweiteren implementiert, das alle Recording Services nicht mehr nur über die Nummer der Aufnahme sondern auch über den Dateinahmen angetriggert werden können.
Ich Empfehle, alle Apps die folgende Services nutzen zu aktualisieren.
GET /recordings/play
POST /recordings/play
GET /recordings/editedfile
GET /recordings
DELETE /recordings
POST /recordings/marks
DELETE /recordings/marks
GET /recordings/cut
POST /recordings/cut
In Zukunft sollten die Anfragen den kompletten Dateinamen enthalten, damit sichergestellt ist, das man auch die richtige Aufnahme löscht, statt eines heißgeliebten Highlights der TV-Geschichte 
Hier ein Beispiel um eine einzelne Aufnahme zu holen bzw. zu löschen:
GET http://<ip>:<port>/recordings/path/to/videodir/my_recording/YYYY-MM-DD.hh.mm.ss-0.rec.<format>
DELETE http://<ip>:<port>/recordings/path/to/videodir/my_recording/YYYY-MM-DD.hh.mm.ss-0.rec.<format>Die EPG Suche kann nun den neuen Parameter date_limit verarbeiten. Es wird ein UNIX-Timestamp erwartet bis zu dem Suchergebnisse ausgespielt werden sollen.
Viel Spaß beim syncen
