Re: [vdr] Recordings Numbering
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
Udo Richter wrote: Am 09.11.2010 16:35, schrieb Matthias Wächter: 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. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Don't recordings actually already have a unique id? It's the name of the directory they are stored in. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
2010/11/10 Ludwig Nussel ludwig.nus...@suse.de: Udo Richter wrote: Am 09.11.2010 16:35, schrieb Matthias Wächter: 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. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Don't recordings actually already have a unique id? It's the name of the directory they are stored in. ACK, keep it simple ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Tue, 09 Nov 2010 23:33:05 +0100, Udo Richter wrote In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? The VDR instance ID (commandline option -i) should become part of the recordings ID. If the instance ID is not 0, we would then get large numbers (InstanceID n | recordingNumber) or we need a separator (%d-%d). The instance ID is part of the filename. So for recordings of a friend, you should use a dedicated instance ID in the filename (something users probably will forget). An other problem to solve: old recordings will need an ID, too. And VDR will not always be able to update info.vdr (e.g. recording on a DVD). Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On 11/10/10 10:38, Frank Schmirler wrote: On Tue, 09 Nov 2010 23:33:05 +0100, Udo Richter wrote In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? The VDR instance ID (commandline option -i) should become part of the recordings ID. If the instance ID is not 0, we would then get large numbers (InstanceID n | recordingNumber) or we need a separator (%d-%d). The instance ID is part of the filename. So for recordings of a friend, you should use a dedicated instance ID in the filename (something users probably will forget). An other problem to solve: old recordings will need an ID, too. And VDR will not always be able to update info.vdr (e.g. recording on a DVD). Hey, hey, guys, get a grip! Let's not make this rocket science ;-) The question at hand is whether the *number* used in the LSTR and LSTT command listings to identify a particular recording or timer, respectively, shall always start at 1 and count up, and be renumbered whenever an item is newly created ot deleted. Or whether that number shall simply count up and never be renumbered (as long as this instance of VDR lives). Anything beyond this is against the KISS principle ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 10:44:59 +0100, Klaus Schmidinger wrote The question at hand is whether the *number* used in the LSTR and LSTT command listings to identify a particular recording or timer, respectively, shall always start at 1 and count up, and be renumbered whenever an item is newly created ot deleted. Or whether that number shall simply count up and never be renumbered (as long as this instance of VDR lives). Anything beyond this is against the KISS principle ;-) ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. 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. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
Hi, Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Here I would agree with you. 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. Anything else would not work with existing svdrp programs. But right now VDR can use only one connection at same time. 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. Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 19:09:46 +0100 Andreas Brachold m...@deltab.de wrote: Hi, Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Here I would agree with you. 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. Anything else would not work with existing svdrp programs. But right now VDR can use only one connection at same time. 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. So the problem is not the recording numbering (for what ?) , but the svdrp limitation to one connection. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
Am 09.11.2010 16:35, schrieb Matthias Wächter: 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. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
should start at 1 and count up as it already does. Also, instead of changing the current numbering system, could using a hash provide you with the same result you're looking for? I would think hashing the first X MB of a recording would suffice to create a unique identifier. If you want a UUID, use a real UUID. (People using SVDRP by hand probably won't like that...) Olaf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On 29.09.2010 23:08, Dominic Evans wrote: Hi all, I was wondering about the recording numbers associated with recordings in the LSTR output. There doesn't seem to be any obvious pattern, is the numbering just random? Well, it starts at 1 and ends at the number of available recordings ;-) It'd be preferable if recordings kept a unique number, that didn't change when every time a recording gets deleted, or a new recording is started. While this sounds feasible, it would also mean that the numbers would get larger and larger over time if VDR runs like 24/7. If this doesn't pose a problem to anybody, I could change this so that every recording an instance of VDR sees would get a unique number, by incrementing a static counter. These numbers would, of course, only be valid within one instance of VDR, and only as long as it actually runs. Once it restarts, the numbers would be reassigned starting at 1. The only question remaining would probably be what to do when the counter wraps over the integer boundary ;-) The same could be applied to the timer numbers. But even with such unique numbers, an SVDRP client that accesses recordings or timers would still need to know whether the VDR instance it is communicating with has been restarted since the last time it fetched the list of timers/recordings. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
