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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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: ...
- 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: ...
- 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?
-
Carsten Koch -
Emil Naepflein -
Helmut Auer -
Klaus Schmidinger -
Lucian Muresan -
Rainer Zocholl -
Reinhard Nissl -
Udo Richter