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.


vdr mailing list

Reply via email to