[vdr] Re: Default video dir

["Reinhard Walter Buchner" <rw.buchner@freenet.de>]

Hi Emil,

> On Sun, 16 Jan 2005 16:00:10 +0100, Reinhard Walter Buchner wrote:
>
> > However, I, too have had a quibble with the way VDR handles the
> > saving and distribution of the recordings. Esp the fact that VDR will
> > place the recordings where there is the most free space.
> This algorithm should be changed in a way so that always all parts of a
> recording are put onto the same partition. I did quick fix by changing
> the algorithm so that the video directories are filled after each other.
> So the risk of a split recording exists only for the last recording on a
> partition.
This would at least be an improvment, but I would rather tell VDR
where to record. Of course, it would be my duty to keep enough free
space. I guess I'm old fashioned, but I'll never trust a computer to make
the right decision for me. Be that symbolic linking or deleting recordings
automatically (or a myriad of other things ;o)), a computer will never
be allowed to do that automagically in my home ;o))


> > However, I do NOT want VDR
> > to record to this drive (esp say half a movie) or split up recordings. 
> > All
> > I want is a script that checks the first HDD for finished (aka edited)
> > recordings and move those to the second HDD as a background task.
> You can apply the change I made to the recordings placement. It will
> fill the first disk and if it is getting full there will be an overflow
> to the second.
> And I have a rather complex perl script to move recordings completly to
> any secondary partition. Only the resume file stays on the the primary
> partition. You may adapt it to your situation.
Feel free to share it if you want to. It'll at least give me some ideas.

> > My next problem is
> > that I want to be able to access the recordings on this VDR from my
> > master VDR. I also want to be able to access the recordings on my
> > master VDR on the living room VDR. I, however, do NOT want
> > VDR to be recording across the two different hardware setups, simply
> > because there is free space available. Here, too, VDR should send a
> > warning message via LAN when the 40 GB disk becomes too full
> > (say 60%).
> I wouldn't do such cross mounts. This may cause problems if one of the
> systems fails. Why not recording directly to the master?
Actually the cross mounts aren't a problem, since the individual VDR
can and should (in my case) only record to it's own dedicated disk. The
living room VDR will NEVER record to the master VDR and vice versa
is also true. However, I would like to share the replay of recordings
amongst the VDRs and the Windows PCs. If a system fails, you just
can't replay recordings on that system. However, this would need a
setup feature that allows the user to at least select the replay drive. I
know you can do this via MPlayer, but then I never liked Mplayer. And
if I use symbolic linking (which I truely despise of), the recording VDR
(i.e the way it is now) will record to whatever drive has free space (once
again a computer is making a decision on it's own. Something thats not
about to happen in my house ;o)) However, the above isn't that simple
either, since VDR needs write access when even to a read only access
would suffice (since VDR wants to write data like marks and replay, etc).
So purely denying write access to the remote drives won't work either.

> I like the central video server with lots of redundant disk space and
> smart clients. This makes the management much easier.
I really like your setup and would love to see it in person, but I don't
relish the idea (for me) of having a server run 24/7 *just* to supply
my video needs. The same problem holds true if I tell a (possibly
diskless) client in the living room to record to my master VDR. You
can bet your socks that when I am fumbling around in the VDR core,
the 75 year old will want to record something to the HDD ;o))


Greets,
Reinhard 


--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.10 - Release Date: 10.01.2005