Am 09.11.2010 13:19, schrieb Dominic Evans:
> Potentially the recordings and timers could all be renumbered to start
> consecutively at zero on some regular schedule (e.g., daily), or via
> some SVDRP call, (similar to what would happen in the event of a
> restart) just as long as they don't change on every new timer or
You just re-introduce the old problem. Don't ever re-number. If you
don't renumber any SVDRP client can be safe in assuming for (nearly) any
time span to mean the same recording as the server when it updates a
Assume a whoppin' 100.000 recordings a day which is more than one per
second. If the recording ID is limited to 32 bits (not more, not less)
you can record for about 43.000 days or 117 years without an overflow.
Let's say you record 100 times that number of recordings, then you'd
overflow in 1.17 years. This _can_ be an issue for permanent (repeating)
recordings, so maybe one could reserve a part of the available space for
permanent recordings so that one never ever gets a collision, not even
in times of wrap-around.
> As numbering sequentially would cause recordings to be numbered in
> order of date/time, presumably the re-numbering that happened on
> restart of VDR should also be changed to number them based on
> date/time rather than alphabetical order?
To repeat myself: Don't ever re-number. Any UI tool should hide the
record ID as it is just a reference link between the applications UI and
VDR running in parallel. Make the ID unique and you will never again see
two clients in parallel deleting the wrong recordings because of
renumbering, or a single client deleting a recording while another
recording was finished, triggering renumbering as well.
vdr mailing list