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?
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.
Cheers, Dom
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
On Sun, Nov 7, 2010 at 7:05 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 29.09.2010 23:08, Dominic Evans wrote:
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 ;-)
What advantage is there to keeping a static total recordings count (I guess you could call it)? Seems the most sane that each recording 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.
Best regards, Derek
On 07.11.2010 16:36, VDR User wrote:
On Sun, Nov 7, 2010 at 7:05 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 29.09.2010 23:08, Dominic Evans wrote:
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 ;-)
What advantage is there to keeping a static total recordings count (I guess you could call it)? Seems the most sane that each recording 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.
I think you're confusing what I suggested with a "universally unique recording ID" or something like that. As far as I understand the problem at hand it's about keeping the recording (and timer) numbers *constant* across operations like creating a new recording/timer or deleting one.
Klaus
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
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.
It should keep the SVDRP connection open, then it will notice a restart.
Olaf
On 7 November 2010 15:05, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
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 ;-)
This sounds like the behaviour I previously expected and I don't see any problem with larger numbers.
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.
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?
Cheers, Dom
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
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
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
2010/11/10 Ludwig Nussel ludwig.nussel@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
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
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
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
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
On Wed, 10 Nov 2010 19:09:46 +0100 Andreas Brachold ml08@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.
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
Potentially the recordings and timers could all be renumbered to start consecutively at zero on some regular schedule (e.g., daily), or via
Renumbering would defeat the purpose of keeping the numbers constant ;-)
With just 8 digits for the ID, you could do 1000 recordings a day and still not overflow the number space in over 270 years. Or more realistically: over a lifespan of 10 years, a VDR instance would reach five-digit numbers only with at least three recordings daily, and six digits with 27 recordings daily.
Olaf
Hi!
On a customers system VDR did 223.402 rcecordings since 25.10.2005, maybe some more, that where not recorded into the database. And the system runs since October 2004. Today VDR records 140 timers and round about 400 GB a day.
I would vote for all time unique id's for timers and recordings. This would make many things easier.
Regards
Marco
Am 09.11.2010 20:21, schrieb Olaf Titz:
Potentially the recordings and timers could all be renumbered to start consecutively at zero on some regular schedule (e.g., daily), or via
Renumbering would defeat the purpose of keeping the numbers constant ;-)
With just 8 digits for the ID, you could do 1000 recordings a day and still not overflow the number space in over 270 years. Or more realistically: over a lifespan of 10 years, a VDR instance would reach five-digit numbers only with at least three recordings daily, and six digits with 27 recordings daily.
Olaf
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Andreas Brachold -
Dominic Evans -
Frank Schmirler -
Klaus Schmidinger -
Ludwig Nussel -
Marco Göbenich -
Matthias Wächter -
Olaf Titz -
Steffen Barszus -
Udo Richter -
VDR User