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 > recording. 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 recording's schedule. 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. - Matthias _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
