On 07.11.2010 16:36, VDR User wrote:
> On Sun, Nov 7, 2010 at 7:05 AM, Klaus Schmidinger
> <klaus.schmidin...@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.


vdr mailing list

Reply via email to