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 n
On Wed, 10 Nov 2010 19:09:46 +0100
Andreas Brachold 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
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
> rec
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
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 wit
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
2010/11/10 Ludwig Nussel :
> 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 s
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
> > recor
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 wo
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 recording
> 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
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 7 November 2010 15:05, Klaus Schmidinger 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
> 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
> 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 i
On 07.11.2010 16:36, VDR User wrote:
> On Sun, Nov 7, 2010 at 7:05 AM, Klaus Schmidinger
> 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
On Sun, Nov 7, 2010 at 7:05 AM, Klaus Schmidinger
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 a
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 ;-
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 n
19 matches
Mail list logo
