Christopher Reimer wrote:
> 2012/9/3 Ludwig Nussel <>:
>> Klaus Schmidinger wrote:
>>> On 09.05.2012 16:36, Manuel Reimer wrote:
>>>> what is the current status in this topic? Anyone working on this?
>>> Attached is a revised version of the patch, as I intend to adopt it
>>> in version 1.7.30.
>> Looks like I missed the discussion when this patch was posted
>> originally. Here are my 2¢'s:
>> +VIDEODIR     = /srv/vdr/video
>> Using /srv is fishy and some distros like Fedora even disallow
>> packages to put anything there. Recordings are automatically created
>> and potentially also automatically deleted. Some of them you want to
>> keep and some you delete after watching. So IMHO they are some kind
>> of spool file where either the machine or a human decides about
>> their fate. So nine years ago when I started packaging vdr for SUSE
>> I decided to use /var/spool/video (could have been /var/spool/vdr
>> too). The second best candidate would be /var/lib/vdr/something I
>> think.
> FHS 2.3 ( says:
> /var/spool contains data which is awaiting some kind of later
> processing. Data in /var/spool represents
> work to be done in the future (by a program, user, or administrator);
> often data is deleted after it has been
> processed.
> I don't think that this applies to recordings.

Well, after you've recorded something you do something with it. Like
watching the recording, deleting it or let vdr delete it when it needs
more free space. If you think of time shifting this matches a spool
directory even more. Of course if your use case mostly is to record
stuff to keep it forever then it doesn't quite match. But then such
recordings should probably be moved to some kind of archive. In any case
using /srv is odd for sure. Better use /var/lib/vdr/... rather than /srv.

>> +CONFDIR      = /var/lib/vdr
>> Even though vdr may update some of the files there itself I still
>> think they belong to /etc to make sure they are included in backups by
>> default.
> Some people mount their /etc read-only. This would break VDR's
> functionality. Nevertheless we already talked about this and most
> people agree with /var/lib/vdr

Currently that might be true. Nevertheless it would be good to enhance
vdr to make it friendlier in that regard though. E.g treating short
lived data like a one shot timer or automatically detected stations
differently than actual configuration like the ordering of stations.


 (o_   Ludwig Nussel
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
16746 (AG Nürnberg) 

vdr mailing list

Reply via email to