DeleteResume patch for vdr 1.3.32.

  The attached patch lets VDR remove a resume.vdr instead of
storing a position in it that points to the beginning.

In big collections of recordings, this reduces the time
to create/update the recordings menu quite a bit, since
VDR does not have to open hundreds of files just to find
out that the information in them is a non-information.

After this patch has made it into standard VDR, the
performance of the recordings menu can be further enhanced
by *never* reading the file, not even when it does exist,
since with the attached patch it is clear that an existing
resume.vdr always means the recording is not rewound.
  

Carsten Koch wrote:
> ...
> After this patch has made it into standard VDR, the
> performance of the recordings menu can be further enhanced
> by *never* reading the file, not even when it does exist,
> since with the attached patch it is clear that an existing
> resume.vdr always means the recording is not rewound.

One of the things that I'm still going to change before version
1.4 is that the current audio track selected during replay will
also be stored in the resume.vdr file. After that the existence
of a resume.vdr file no longer necessarily means that the
the recording is not rewound.

Thats' why I haven't adopted your patch - just in case you're
wondering. The reading of the video directory is going to be
put into a separate thread, so that the user won't experience
any more delays, anyway.

Klaus
  

Klaus Schmidinger wrote:
...
> The reading of the video directory is going to be
> put into a separate thread, so that the user won't experience
> any more delays, anyway.

I hereby volunteer to beta-test that change. :-)

I currently have 519 recordings on 9 disks.
Even with my patch it takes 30-40 seconds to bring up
the recordings menu.
So some of my family members often inadvertendly start
the first recording in the first folder because they keep
pressing OK thinking VDR did not receive the previous OK
command.

I still believe that your original concept to store all
data to be displayed by the recordings menu is better
than a concept that requires not only directory entries,
but also files to be read for building the recordings menu.

Of course, aside from reducing the time to build the
recordings menu, several things can be done to make
the problem I am seeing at least look better:

1) The recordings menu could come up immediately when OK
    is pressed and fill in its contents in parallel.
    (I guess this is what you are planning to do with
     the separate thread)

2) You could make two passes and read only directory
    entries in the first pass and resume.vdr files in
    the second pass.

3) You could spawn a separate thread for every disk
    you process, so waiting for 9 disks to spin up does
    not take 9*spinup_time, but only 1*spinup_time.

4) Of course, Ralf Müller's "Patch to avoid file system
    buffer trashing" will also help a lot.


What do you think?


Carsten.
  

Carsten Koch wrote:
> Klaus Schmidinger wrote:
> ...
> 
>> The reading of the video directory is going to be
>> put into a separate thread, so that the user won't experience
>> any more delays, anyway.
> 
> 
> I hereby volunteer to beta-test that change. :-)
> 
> I currently have 519 recordings on 9 disks.
> Even with my patch it takes 30-40 seconds to bring up
> the recordings menu.
> So some of my family members often inadvertendly start
> the first recording in the first folder because they keep
> pressing OK thinking VDR did not receive the previous OK
> command.
> 
> I still believe that your original concept to store all
> data to be displayed by the recordings menu is better
> than a concept that requires not only directory entries,
> but also files to be read for building the recordings menu.
> 
> Of course, aside from reducing the time to build the
> recordings menu, several things can be done to make
> the problem I am seeing at least look better:
> 
> 1) The recordings menu could come up immediately when OK
>    is pressed and fill in its contents in parallel.
>    (I guess this is what you are planning to do with
>     the separate thread)

Exactly.

> 2) You could make two passes and read only directory
>    entries in the first pass and resume.vdr files in
>    the second pass.

Well, depends on how good 1) will work.

> 3) You could spawn a separate thread for every disk
>    you process, so waiting for 9 disks to spin up does
>    not take 9*spinup_time, but only 1*spinup_time.

Since it's going to happen in background I guess this
shouldn't be that much of a problem.

> 4) Of course, Ralf Müller's "Patch to avoid file system
>    buffer trashing" will also help a lot.

Certainly - I just haven't had time to look into it, yet.

Klaus
  

Klaus Schmidinger wrote:
> The reading of the video directory is going to be
> put into a separate thread, so that the user won't experience
> any more delays, anyway.

Another idea how to speed things up:
Build up a cache file that keeps a copy of all resume.vdr and similar
files, together with a time stamp. Reading one big file is faster than
reading many small files. Only read the resume.vdr if the file
modification date doesn't match the cached time stamp.

Cheers,

Udo
  

On Sun, 11 Sep 2005 18:00:15 +0200, Carsten Koch wrote:

> I hereby volunteer to beta-test that change. :-)

Me too! ;-)

> 
> I currently have 519 recordings on 9 disks.

599 recordings on 10 disk

> Even with my patch it takes 30-40 seconds to bring up
> the recordings menu.

Only for the first time. I currently see much more delays because
vdradmin scans the schedule for autotimers.

> So some of my family members often inadvertendly start
> the first recording in the first folder because they keep
> pressing OK thinking VDR did not receive the previous OK
> command.

Here I miss the message that the recordings are being scanned as it was
in the old 1.2 version.

> I still believe that your original concept to store all
> data to be displayed by the recordings menu is better
> than a concept that requires not only directory entries,
> but also files to be read for building the recordings menu.

I agree. If this could not be avoided that it would be ok to cache the
content of the resume file as with all the other infos.

> 1) The recordings menu could come up immediately when OK
>     is pressed and fill in its contents in parallel.
>     (I guess this is what you are planning to do with
>      the separate thread)

Yes, this would be ok.

> 2) You could make two passes and read only directory
>     entries in the first pass and resume.vdr files in
>     the second pass.

It should be done in a single pass because the directories have to be
read anyway. 

> 
> 3) You could spawn a separate thread for every disk
>     you process, so waiting for 9 disks to spin up does
>     not take 9*spinup_time, but only 1*spinup_time.

I would disable spin up/down of disks anyway. And vdr doesn't know what
disks are involved.

Emil
  

Emil Naepflein wrote:
...
>>3) You could spawn a separate thread for every disk
>>    you process, so waiting for 9 disks to spin up does
>>    not take 9*spinup_time, but only 1*spinup_time.
> 
> 
> I would disable spin up/down of disks anyway.

Is this mainly because you want more noise in
the living room, because you want the disks to
die sooner, because you want more heat in your
VDR PC or because you want it to waste more power? ;-)


> And vdr doesn't know what disks are involved.

I am using only a single /video directory on the system disk.
Directly under /video, I have one directory for each genre.
Those are symbolic links pointing to other disks, some of
which are local disks, others are NFS-mounted.
It would not be hard for VDR to follow my links and find
out which disks are really involved, but I guess currently
there is no such code in VDR.

Carsten.
  

Hi

>>I would disable spin up/down of disks anyway.
>>    
>>
>
>Is this mainly because you want more noise in
>the living room, because you want the disks to
>die sooner, because you want more heat in your
>VDR PC or because you want it to waste more power? ;-)
>
>  
>
You have 9 disks in the living room ? That sounds crazy to me :-)
You are right with noise and heat, but the disks will live longer when 
you disable spindown.

>  
>
>>And vdr doesn't know what disks are involved.
>>    
>>
>
>I am using only a single /video directory on the system disk.
>Directly under /video, I have one directory for each genre.
>Those are symbolic links pointing to other disks, some of
>which are local disks, others are NFS-mounted.
>It would not be hard for VDR to follow my links and find
>out which disks are really involved, but I guess currently
>there is no such code in VDR.
>  
>
Surely not, and vdr should not mind what hardware is behind /video.
But there is surely a way to put stuff like that into a plugin ...
  

Helmut Auer wrote:
...
> You have 9 disks in the living room ?

This is getting a bit off-topic, but to answer your question:
The main VDR system in the living room has 4 disks, just to make
good use of the IDE controller on the main board.
I am using SAMSUNG SP1604N, which are very quiet.
Actually, the DLP beamer makes a lot more noise.  ;-)
I am thinking of putting a diskless system into the living room.
This may have to wait until I figure out how to squeeze 14
disks into my server (it currently has 10).


> You are right with noise and heat, but the disks will live longer when 
> you disable spindown.

That obviously depends on how often you spin them up and down.
I would assume that a disk which is on for 2 hours a day
and off for 22 (so it spins up/down once per day)
lives *a lot* longer than a disk that is on for 24 hours a day.
What do you think?

Carsten.
  

Hi,

Carsten Koch wrote:

> I am using SAMSUNG SP1604N, which are very quiet.

That's true.

> That obviously depends on how often you spin them up and down.
> I would assume that a disk which is on for 2 hours a day
> and off for 22 (so it spins up/down once per day)
> lives *a lot* longer than a disk that is on for 24 hours a day.
> What do you think?

Depends on the drive: a Seagate Cheetah's MBTF is only valid if the 
drive is spinning almost continuously. The docs allow only 30 
powercycles per year.

Bye.
  

Hi
>
>   
>> You are right with noise and heat, but the disks will live longer when 
>> you disable spindown.
>>     
>
> That obviously depends on how often you spin them up and down.
>   
Thats surely right :-)
> I would assume that a disk which is on for 2 hours a day
> and off for 22 (so it spins up/down once per day)
> lives *a lot* longer than a disk that is on for 24 hours a day.
> What do you think?
>   
I'm far away from having exactly an idea where the break even point is, 
but I'd guess that one spinup will cost some hours of the lifetime of 
the harddisk.
So in a "usual" living room scenario where the recordings button will be 
pressed sometimes I'd prefer not switching off harddisks - btw. usually 
there is only one disk in a living room system and with kernel 2.6. you 
will drive crazy when you try to get that beast sleeping :-)

That looks different on a server system ...
  

Carsten.Koch@icem.com(Carsten Koch)  11.09.05 18:00


>Klaus Schmidinger wrote:
>...
>> The reading of the video directory is going to be
>> put into a separate thread, so that the user won't experience
>> any more delays, anyway.

>I hereby volunteer to beta-test that change. :-)

>I currently have 519 recordings on 9 disks.
>Even with my patch it takes 30-40 seconds to bring up
>the recordings menu.
>So some of my family members often inadvertendly start
>the first recording in the first folder because they keep
>pressing OK thinking VDR did not receive the previous OK
>command.

That's a generall problem of VDR key processing too.
LIRC commands are not time stamped.
So VDR can't discard "superflous" keys.
Maybe it can help, if VDR would direct LIRC keys into
the "big byte bucket" to discard superflous keys before starting 
to do anthing, and redirect it back to the real processing when done?
The "escape" key should not be directed into bb,
so an action can always be aborted.

Of course these 30...40s are completely inacceptable!
5sec is the limit of any action!
If the action lasts longer the program MUST show
a progress bar or other signs of life...

But there will always be actions which takes "longer".
It is a not acceptable "human interface" that VDR is using the
"queued" keys seconds(!) after pressed. That was state of the computer 
art in the 80th...


Rainer
  

On Sun, 11 Sep 2005 20:50:39 +0200, Carsten Koch wrote:

> Emil Naepflein wrote:
> ...
> >>3) You could spawn a separate thread for every disk
> >>    you process, so waiting for 9 disks to spin up does
> >>    not take 9*spinup_time, but only 1*spinup_time.
> > 
> > 
> > I would disable spin up/down of disks anyway.
> 
> Is this mainly because you want more noise in
> the living room, because you want the disks to
> die sooner, because you want more heat in your
> VDR PC or because you want it to waste more power? ;-)

First, my server is not in my living room. Second, I hate when it takes
multiple seconds until I get a response. Third, with RAID all disks
would be either up or down. The power saving would be minimal. I save
mor power by using NVRAM wakeup.

> I am using only a single /video directory on the system disk.
> Directly under /video, I have one directory for each genre.
> Those are symbolic links pointing to other disks, some of
> which are local disks, others are NFS-mounted.

My logical layout is similar but the recordings are spread over multiple
RAID partitions (but files of one recording are all on the same).

> It would not be hard for VDR to follow my links and find
> out which disks are really involved, but I guess currently
> there is no such code in VDR.

There was already the diskussion to drop the support for multiple disks.
I don't think that a more complex scheme to handle the spin up/down of
disks has any chance to be introduced.

Emil
  

On Sun, 11 Sep 2005 21:30:19 +0200, Carsten Koch wrote:

> That obviously depends on how often you spin them up and down.

Yes

> I would assume that a disk which is on for 2 hours a day
> and off for 22 (so it spins up/down once per day)
> lives *a lot* longer than a disk that is on for 24 hours a day.
> What do you think?

The problem is that you really don't know how often in spins up/down per
day. Depending on the parameters it can be 100s of times or never.

I disabled spin up/down and stop the complete server. On average I have
approximately 2-5 complete power cycles a day, depending on the
distribution of recordings. The power down is handled by NVRAM and power
up is done by NVRAM, etherwake or by a telefon call to my fritz box. ;-)

Emil
  

Emil Naepflein wrote:
[...]
> I disabled spin up/down and stop the complete server. On average I have
> approximately 2-5 complete power cycles a day, depending on the
> distribution of recordings. The power down is handled by NVRAM and power
> up is done by NVRAM, etherwake or by a telefon call to my fritz box. ;-)

I don't know, maybe this is OT, maybe others are interested too, or
maybe this deserves a completely new thread, but to me it sounds very
interesting. For those who don't know yet, the Fritz!Box is a router
family made by AVM, very popular in Germany.
Are there any pointers on how to handle powerup by etherwake and /or the
Fritz!Box? NVRAM is set up on my VDR box and works well, I also have a
Fritz!Box with slightly modified firmware (I occasionaly read the
http://www.ip-phone-forum.de), and it would be cool if I could also
wakeup my server and my vdr box remotely via the Fritz!Box, I only
didn't find a clear howto for this on that forum, is there any?