On Wed, 10 Nov 2010 19:09:46 +0100, Andreas Brachold wrote > Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: > > Guess a touch /video/.update would result in new IDs for all > > recordings. So one must be aware that if an ID is no longer available, > > the corresponding item has not necessarily been deleted. > > Why ? This is not even necessary ! > Missing recordings should simple remove from list (LSTR) and new > recordings should added at end of list. Currently VDR simply forgets and rereads all recordings. To apply only the changes, there's quite a lot to compare to decide if two recording objects are still the same - down to the contents of the info file. As an SVDRP program has to be able to deal with VDR restarts anyway, why not treat such a complete renumbering the same way? > Anything else would not work with existing svdrp programs. Well, at the moment we don't even have reliable IDs and existing SVDRP programs seem to cope with it more or less. How could that become worse? > >From my point of view (xxv as svdrp client), I would not block the > connection permanent. And I do not would to reread every time any > recordings. I don't think anyone touches the .update file every few minutes. In remotetimers, before modifying/deleting an item I retrieve this item and compare it to what I've retrieved earlier. If it differs, the action is aborted and I refresh the whole list. And I probably have to keep the implementation that way. It's the only way to detect if an item has been modified in the meantime - even with reliable IDs and even with multi connection support. However exposing e.g. the VDR start time (unix timestamp) plus cRecordings/cTimers::state to SVDRP clients would help to detect restarts and list modifications beforehand. Frank _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
