[vdr] Filesystem hierachy standard patch needs review.

[Christopher Reimer]

Hi Mailinglist,

could someone please review the attached patch? It's originally posted by
Maniac in this thread -->
http://www.vdr-portal.de/board60-linux/board14-betriebssystem/p1054966-vdr-verzeichnisse-nach-filesystem-hierarchy-standard-fhs-richtig-ablegen/#post1054966

The documentation and some Makefile changes are my work. The main code
changes are Maniac's work.


I hope the code as well as the documentation is ok, so that the patch can
be added in the next VDR Version.

Thanks,

Christopher Reimer

[Gero]

Hi,

Post by Christopher Reimer
I hope the code as well as the documentation is ok, so that the patch can
be added in the next VDR Version.

The comment (line 8ff) was a good joke on forum discussion thread, but keeping
it that way sounds really offending to me.
I don't think, its a good choice.

kind regards

Gero

[Klaus Schmidinger]

Post by Gero
Hi,

Post by Christopher Reimer
I hope the code as well as the documentation is ok, so that the patch can
be added in the next VDR Version.

The comment (line 8ff) was a good joke on forum discussion thread, but keeping
it that way sounds really offending to me.
I don't think, its a good choice.

But isn't that exactly what happens then? ;-)
The files *are* spread all over the place.
Besides, who reads the INSTALL file, anyway... ;-)

Klaus

[Christopher Reimer]

I think there's one problem left.

Doesn't VDR try to create the "plugins" subdir?

VDR runs usually as user. Most distribution maintainer will give VDR write
permission for the cache dir and the config dir. But not for the resource
dir.

To prevent these permission problems I think it's neccessary to change the
Makefile from

install-dirs:
@mkdir -p $(DESTDIR)$(VIDEODIR)
@mkdir -p $(DESTDIR)$(CONFDIR)
@mkdir -p $(DESTDIR)$(RESDIR)
@mkdir -p $(DESTDIR)$(CACHEDIR)


to

install-dirs:
@mkdir -p $(DESTDIR)$(VIDEODIR)
@mkdir -p $(DESTDIR)$(CONFDIR)/plugins
@mkdir -p $(DESTDIR)$(RESDIR)/plugins
@mkdir -p $(DESTDIR)$(CACHEDIR)/plugins

or at least

install-dirs:
@mkdir -p $(DESTDIR)$(VIDEODIR)
@mkdir -p $(DESTDIR)$(CONFDIR)
@mkdir -p $(DESTDIR)$(RESDIR)/plugins
@mkdir -p $(DESTDIR)$(CACHEDIR)

[Gero]

Post by Klaus Schmidinger

Post by Gero
The comment (line 8ff) was a good joke on forum discussion thread, but
keeping it that way sounds really offending to me.
I don't think, its a good choice.

But isn't that exactly what happens then? ;-)
The files *are* spread all over the place.
Besides, who reads the INSTALL file, anyway... ;-)

Well, *I* think, that there's a big difference between keeping things in order
compared to spreading things all over the place.

The one who eats where he shits, surely has a single place for his *IO* - but
I neither consider this habit as recommended, nor exemplary.
... but well - after all its just my opinion.

kind regards

Gero

[VDR User]

Post by Gero
Well, *I* think, that there's a big difference between keeping things in order
compared to spreading things all over the place.

I can't stand when things are installed all over the place. It's too
messy and pointless in my opinion. I'm in the habit of simply running
VDR from it's source dir and using symlinks. It makes things very easy
like archiving working/test sources, changing between versions without
any needless 'reinstall'ing, etc. I see no benefit what-so-ever to
installing over running VDR from the source dir, unless of course
you're using pre-compiled binaries.

As far as the patch, is it really necessary to split the files up even
further? What is the real benefit? Also, don't different distros use
different dir structures, so what's common on some may not be on
others? If this is an attempt to standardize something, it's probably
best to find a standard that exists across _all_ distros (if this
isn't the case here).

[Gero]

Post by VDR User
I can't stand when things are installed all over the place.

Let's take a quick look at real life:
if you need to exchange the tooth belt on your motorcycle - will you perform
that task in your living room?

if you visit your friend for the first time and you look for a cold beer - will
you look in his bedroom?

In real life we all "spread our things all over the house" to keep them in
order. The refrigerator will be placed in the kitchen, the car in the garage
and your bed will most probably be in your bedroom.

If you like to sleep on toilet or shit in your kitchen - I don't mind.
For me, people that like to keep their PC in order behave quite natural,
there's no need to offend them for thinking different.


kind regards

Gero

[Mikko Tuumanen]

Post by Gero
In real life we all "spread our things all over the house" to keep
them in order.

Exactly. And the point of spreading files all over the directory
tree (not filesystem) is to be able to easily:

- split the tree into several filesystems that have different properties
such as size, speed, availability when the network is up, etc.
- make part of the tree read only (to protect it from some problems)
- make part of the tree shared between computers
- and some parts shared between computers of different cpu architectures

For example it should be possible to make /usr read only and
share /usr/share between different cpu architectures.

[VDR User]

Post by Gero

Post by VDR User
I can't stand when things are installed all over the place.

if you need to exchange the tooth belt on your motorcycle - will you perform
that task in your living room?
if you visit your friend for the first time and you look for a cold beer - will
you look in his bedroom?
In real life we all "spread our things all over the house" to keep them in
order. The refrigerator will be placed in the kitchen, the car in the garage
and your bed will most probably be in your bedroom.

I don't spread things all over my house and from the sound of it
neither do you(?). All my bathroom items are in the bathroom. All my
kitchen items are in my kitchen. All my office items are in my office.
I keep everything VDR in one place. It works great (for me). I see no
reason to put a VDR binary in one dir, plugin binaries in another dir,
config files in another dir, this stuff in this dir, that stuff in yet
another dir..

Post by Gero
If you like to sleep on toilet or shit in your kitchen - I don't mind.
For me, people that like to keep their PC in order behave quite natural,
there's no need to offend them for thinking different.

I'm not sure who is offended but if my personal preference & opinion
offends you, maybe you shouldn't value other peoples preferences &
opinions so much because it's not a big deal.

Instead of going on about that stuff, which is completely irrelevant,
maybe someone can answer what I've already asked:

"As far as the patch, is it really necessary to split the files up even
further? What is the real benefit? Also, don't different distros use
different dir structures, so what's common on some may not be on
others? If this is an attempt to standardize something, it's probably
best to find a standard that exists across _all_ distros (if this
isn't the case here)."

Cheers

[Gero]

I don't spread things all over my house ...
All my bathroom items are in the bathroom.
All my kitchen items are in my kitchen.
All my office items are in my office.

But you use all that items on different tasks in different places.
I guess, most of us will do.

So imagine a family with 2 parents, 6 children and all of them like the same
order as above: all bathroom items in the bathroom, all kitchen items in the
kitchen, ...
But every person knows to distinguish its own items from the others items in
the same room. There's no problem in real life.

So why don't you want allow such an order in vdr-systems?
Imagine the bathroom items are the vdrs databases, the kitchen is the
recording root and the office is the binary and configuration...

... if my personal preference & opinion offends you, ...

NO - it does not!

I support the freedom of every individual to live at its own taste.

I can support your different way of thinking without the need to like the way
you live. And of cause without to follow your way of living.

maybe you shouldn't value other peoples preferences &
opinions so much because it's not a big deal.

I don't argue about other people preferences.

May be you lost the start of discussion.

I only argued against the *comment* which I understand as kind of offending
people, that like things in order. I don't mind, if you laugh about my way of
living / thinking.

But putting such a comment in the INSTALL instructions, that everyone needs to
read, that likes to install a vdr on its own - is not a trivial matter.
Such a comment in code is no problem at all, but INSTALL or help-files or other
*public* files is quite different.

In OO-terms, the INSTALL is part of the public interface and that comment is
not right for the public interface. It might be ok, in the internal stuff.
I laughed a lot when I first read it, but my humor may not be standard ;)


Well, that's my thoughts.
I'm not known to be very polite, but I try to improve myself every day a bit
further.


kind regards

Gero

[Klaus Schmidinger]

[ ... arguments about pros and cons of FHS ... ]

The purpose of this thread is not to discuss the pros and cons of the FHS
vs. having all files of an application in one place. Clearly these two
approaches are so fundamentally different that there will never be a
common ground. And any comparison to real-life behavoir apparently can
always be used both ways. So let's just cut the crap here and focus on
what this is really about.

Christopher Reimer has posted a patch that introduces a way of making
VDR store its files according to the FHS, in case somebody wants to
do that. This patch will *NOT* change VDR's default behavior of storing
all files in one place. If you want to make VDR use the FHS, you need to
use the respective command line options or make the proper entries in your
Make.config file.

What I want to see in this thread are ACKs (or NACKs) from people who have actually
reviewed the patch, and preferably have applied and tested it.
Does the patch actually do what it is suppposed to do?
Does it retain the default behavior of storing all files in one place?
Does it break anything?

Unless I get at least three ACKs for this patch, it won't go into the
official VDR source. So far, I haven't seen a single one, so the status is
currently "not accepted".

As for the "offending" comment in INSTALL: it was me who insisted in this,
so please don't blame it on Christopher. I just want to make it very clear
to anybody who uses this feature that this will result in VDR's files being
stored in many different places. VDR users have a tendency to blindly apply
any patches the can find, without really considering whether this does
anything useful for them ;-)

Klaus

[Stefan Taferner]

Post by VDR User

Post by Gero
Well, *I* think, that there's a big difference between keeping things in order
compared to spreading things all over the place.

I can't stand when things are installed all over the place. It's too
messy and pointless in my opinion. I'm in the habit of simply running
VDR from it's source dir and using symlinks. It makes things very easy
like archiving working/test sources, changing between versions without
any needless 'reinstall'ing, etc. I see no benefit what-so-ever to
installing over running VDR from the source dir, unless of course
you're using pre-compiled binaries.

I do not think that you would do this with your entire Linux system.... ;-)

Before the file hierarchy standard, Linux was a bit messy. Nowadays one
knows where to find things. Configuration for example in /etc - a no
brainer.
It makes life much easier, e.g. when backing up the system's configuration.

You can (guessed) most probably still start your VDR with the directories
given as commandline arguments. Sure, this means some custom script
for you. But the FHS helps many other people.

Kind regards,
Stefan

[Udo Richter]

Post by Christopher Reimer
could someone please review the attached patch? It's originally posted
by Maniac in this thread -->

On the original topic, I see room for one improvement:

The defaults of the new --cachedir and --resdir parameter are the
defaults set by Make.config's CACHEDIR and RESDIR. This is a minimal
change in behavior to previous versions, where these were handled by
--video and --config. So any old VDR that gets updated will behave
different in case that --video or --config is set, and now needs to also
have --cachedir and --resdir set. On the other hand, there needs to be a
way for distributions to set their defaults so that VDR finds them
automatically.


My suggestion:
Allow to keep the default CACHEDIR and RESDIR un-set (empty), and if
--cachedir or --resdir is not present, default to whatever --video and
--config is actually set to. That way, the package builder can decide
whether to set CACHEDIR and RESDIR or not, and if they're set, he has to
make sure that the startup scripts get modified to support --cachedir
and --resdir if necessary.

For an extra, an explicit --cachedir="" and --resdir="" could also
override an explicit CACHEDIR and RESDIR and revert to duplicating
--video and --config.


Cheers,

Udo

[Christopher Reimer]

Post by Christopher Reimer
could someone please review the attached patch? It's originally posted
by Maniac in this thread -->

I tried to fix this on my own. So be careful

In case CACHEDIR and VIDEODIR are equal and Cachdir isn't set via command
line while Videodir is set. It should now use the Videodir as Cachedir.

It is a bit confusing that there's no DEFAULTVIDEODIR in vdr.c

RESDIR and CONFDIR should work similar.


Nevertheless isn't ConfigDir also staying default, in case the VideoDir is
changed via --video.


Christopher

[Manuel Reimer]

Post by Udo Richter
Allow to keep the default CACHEDIR and RESDIR un-set (empty), and if
--cachedir or --resdir is not present, default to whatever --video and
--config is actually set to. That way, the package builder can decide
whether to set CACHEDIR and RESDIR or not, and if they're set, he has to
make sure that the startup scripts get modified to support --cachedir
and --resdir if necessary.
For an extra, an explicit --cachedir="" and --resdir="" could also
override an explicit CACHEDIR and RESDIR and revert to duplicating
--video and --config.

It is difficult to read your description (and no, I didn't understand it). How
would you want to document this in a way, someone actually understands it?

If someone updates from 1.6 to an (upcoming) 2.0, then two new parameters to VDR
won't be his only problem, so I vote against bloating the VDR sourcecode just to
add some difficult logic on how and when directories are set by compile
parameters or VDR parameters.

Yours

Manuel

[Udo Richter]

Post by Manuel Reimer
It is difficult to read your description (and no, I didn't understand
it). How would you want to document this in a way, someone actually
understands it?

I guess I have to find a way to be more clear...

Ok, second attempt:
- Makefile does not set CACHEDIR and RESDIR
- Make.config *can* set CACHEDIR and RESDIR, or not.
- If --cachedir or --resdir is set by command line, use them.
- If not, default to CACHEDIR and RESDIR.
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.


Patched patch attached. ;)
Needs documentation updated though.


Cheers,

Udo

[Christopher Reimer]

Post by Udo Richter
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.

No, CACHEDIR and RESDIR should work in the same behaviour as CONFDIR or
VIDEODIR.

This sounds a bit like you set all your directories by command line. Sorry,
but why don't you just use Make.config like everyone else does.

[VDR User]

On Sun, Apr 8, 2012 at 10:57 AM, Christopher Reimer

Post by Christopher Reimer

Post by Udo Richter
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.

No, CACHEDIR and RESDIR should work in the same behaviour as CONFDIR or
VIDEODIR.
This sounds a bit like you set all your directories by command line. Sorry,
but why don't you just use Make.config like everyone else does.

I know several people who set their directories on the command line
and ignore maintaining Make.config completely so it's not true
everyone uses Make.config.

Cheers

[Christopher Reimer]

Post by VDR User
I know several people who set their directories on the command line
and ignore maintaining Make.config completely so it's not true
everyone uses Make.config.

OK, that could be possible, although I don't understand why.

Let's wait what Klaus says.

[VDR User]

On Sun, Apr 8, 2012 at 2:11 PM, Christopher Reimer

Post by Christopher Reimer

Post by VDR User
I know several people who set their directories on the command line
and ignore maintaining Make.config completely so it's not true
everyone uses Make.config.

OK, that could be possible, although I don't understand why.

For me personally, I set these things (and many others) in my
(multi-purpose) tv script so I have most settings in one place. I
prefer consolidating when possible simply because it's easier to
maintain in my opinion. Any time I update VDR for example, I don't
have to worry about modifying or copying an archived Make.config. I
just compile the source, set my /vdr symlink to it and "tv restart".

Cheers

[Klaus Schmidinger]

Post by VDR User
I know several people who set their directories on the command line
and ignore maintaining Make.config completely so it's not true
everyone uses Make.config.
OK, that could be possible, although I don't understand why.
Let's wait what Klaus says.

The only condition I want to be met is that when building the original,
unpatched VDR out of the box, without any user defined Make.config etc.,
it needs to behave just like it does now.

However, there is one thing in the current behavior that I would even
consider a bug: if one starts VDR with

vdr -v /mydir

it uses /mydir as the video directory, but still uses /video for the
configuration files. I believe that as long as there is no explicit
-c option given, the config directory should follow what's given in
the -v option. So I wouldn't mind if this was fixed along with implementing
the FHS stuff ;-) (or in a separate step).

Klaus

[Christopher Reimer]

Post by Klaus Schmidinger
However, there is one thing in the current behavior that I would even
consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the
configuration files. I believe that as long as there is no explicit
-c option given, the config directory should follow what's given in
the -v option. So I wouldn't mind if this was fixed along with implementing
the FHS stuff ;-) (or in a separate step).

Ok, maybe Udo can add this to the patch.

Udo, please also mind the additional Makefile change I mentioned before.

I can't find a special place where to add this to the documentation. In
addition I think it's self explanatory

[Pertti Kosunen]

Post by Klaus Schmidinger
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the
configuration files. I believe that as long as there is no explicit
-c option given, the config directory should follow what's given in
the -v option.

Shouldn't it follow option given at ./configure?

[Klaus Schmidinger]

Post by Pertti Kosunen

Post by Klaus Schmidinger
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the
configuration files. I believe that as long as there is no explicit
-c option given, the config directory should follow what's given in
the -v option.

Shouldn't it follow option given at ./configure?

What "./configure"???

Klaus

[Pertti Kosunen]

Post by Klaus Schmidinger
What "./configure"???

When compiling VDR from source, "./configure ; make ; make install".

[Klaus Schmidinger]

Post by Pertti Kosunen

Post by Klaus Schmidinger
What "./configure"???

When compiling VDR from source, "./configure ; make ; make install".

There is no "./configure" in the VDR source.

Klaus

[Udo Richter]

Post by Klaus Schmidinger
However, there is one thing in the current behavior that I would even
consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the
configuration files. I believe that as long as there is no explicit
-c option given, the config directory should follow what's given in
the -v option.

You're sure about -c following -v? It worked that way until 1.5.8, but
has been dropped in favor of the final changes regarding CONFDIR in
1.5.11. I don't see any reason to change that. Or did you mess up
--config with --cachedir? Happened to me too.


In the latter case:
In my patch, the cacheDirectory follows the VideoDirectory, even if the
latter is set by --video, but only as long as CACHEDIR is un-set. (Same
applies to --config and RESDIR.)

I'm not sure whether this should also be the case if VDR is compiled to
be FHS compliant. In that case users should know about the various
folders, and setting a --video directory should not have precedence over
CACHEDIR=/var/lib/vdr. The only thing I could think of is to check
whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow
--video, but I would prefer to not use such hacks.

[Klaus Schmidinger]

Post by Udo Richter

Post by Klaus Schmidinger
However, there is one thing in the current behavior that I would even
consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the
configuration files. I believe that as long as there is no explicit
-c option given, the config directory should follow what's given in
the -v option.

You're sure about -c following -v? It worked that way until 1.5.8, but
has been dropped in favor of the final changes regarding CONFDIR in
1.5.11. I don't see any reason to change that. Or did you mess up
--config with --cachedir? Happened to me too.

I surely didn't mean --cachedir because my VDR doesn't have that option (yet) ;-).
A while ago I ran a test and wanted to use a different video directory,
so I started VDR with the -v option. I was surprised to see that it still
loaded the config files from the default /video directory.

Post by Udo Richter
In my patch, the cacheDirectory follows the VideoDirectory, even if the
latter is set by --video, but only as long as CACHEDIR is un-set. (Same
applies to --config and RESDIR.)
I'm not sure whether this should also be the case if VDR is compiled to
be FHS compliant. In that case users should know about the various
folders, and setting a --video directory should not have precedence over
CACHEDIR=/var/lib/vdr. The only thing I could think of is to check
whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow
--video, but I would prefer to not use such hacks.

Currently VDR has only two directories, 'video' and 'config'.
The idea is that by default the video directory is /video, and
the config directory is the same. If -v is given, this changes the
video directory, and since config follows video (or at least is supposed to),
the config files will be loaded from the new video directory. Only
if there is an explicit -c option shall the config directory be
different from the video directory.

I'd like to see a similar mechanism for the two new directories
'cache' and 'resource'. By default they follow 'config' and can only
be different if the respective options are given.
The default values for 'cache' and 'resource' shall be empty, in which
case they follow 'config'. If VDR is compiled with non-empty values
for 'cache' and/or 'resource', simply let them no longer follow 'config'
(same behavior as if a command line option has been given).

Don't know whether the patch already behaves this way (haven't checked),
but that's the way it should be.

Klaus

[Manuel Reimer]

Post by Udo Richter
- Makefile does not set CACHEDIR and RESDIR
- Make.config *can* set CACHEDIR and RESDIR, or not.
- If --cachedir or --resdir is set by command line, use them.
- If not, default to CACHEDIR and RESDIR.
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.
Patched patch attached. ;)
Needs documentation updated though.

Do so. I guess it is nearly impossible to document this in a way, a user actually understands.

Yours

Manuel

[Anssi Hannula]

FHS patch

This change would be welcome (I'm the VDR package maintainer of Mageia
distribution), though it hasn't really been a big issue for me.

+CACHEDIR = /var/cache/vdr
+CONFDIR = /var/lib/vdr

Just for the record, this is a bit against FHS rules ("Users must never
need to modify files in /var/lib to configure a package's operation."),
but there really is not better option either... (maybe fhs-discuss@
could be asked for a clarification).

+LOCDIR = $(PREFIX)/share/locale
+PLUGINLIBDIR = $(PREFIX)/lib/vdr
+RESDIR = $(PREFIX)/share/vdr
+VIDEODIR = /srv/vdr/video0

Ditto here, "/srv contains site-specific data which is served by this
system.", which video data really isn't. (btw, why 'video0' and not
'video' like is VDR default?)

On Mandriva/Mageia packages I use '/var/lib/vdr/config' and
'/var/lib/vdr/video', but as I said, they aren't really any better than
your suggestions :)

Maybe just add a note that the INSTALL example doesn't really conform to
current FHS?

[Steffen Barszus]

On Sat, 07 Apr 2012 19:24:17 +0300

Post by Anssi Hannula

FHS patch

This change would be welcome (I'm the VDR package maintainer of Mageia
distribution), though it hasn't really been a big issue for me.

+CACHEDIR = /var/cache/vdr
+CONFDIR = /var/lib/vdr

Just for the record, this is a bit against FHS rules ("Users must
never need to modify files in /var/lib to configure a package's
operation."), but there really is not better option either... (maybe

vdr has 2 types of conf files -
1) internal databases - like channels.conf, setup.conf
2) real conf files like scr.conf, diseqc.conf etc

1 should be in /var/lib/vdr
2 should be in /etc/vdr/

This is kind of hard to handle properly as vdr doesn't make this
distinction. conf files in /var/lib is a no-go, application changed
files in /etc is a no-go either.

Post by Anssi Hannula

+LOCDIR = $(PREFIX)/share/locale
+PLUGINLIBDIR = $(PREFIX)/lib/vdr
+RESDIR = $(PREFIX)/share/vdr
+VIDEODIR = /srv/vdr/video0

Ditto here, "/srv contains site-specific data which is served by this
system.", which video data really isn't. (btw, why 'video0' and not
'video' like is VDR default?)

If video is served by vdr or not is a bit of opinion. IMHO recordings
is THE data served by vdr, it should not be hidden somewhere
in /var/lib , in yavdr we also make it available in the local network
by smb and nfs - those we use this directory. video0 , because it
allows for easy extension of storage space, without reconfiguring vdr,
video1, video2 and videoX will be used autmatically by vdr at next
start.

Post by Anssi Hannula
On Mandriva/Mageia packages I use '/var/lib/vdr/config' and
'/var/lib/vdr/video', but as I said, they aren't really any better
than your suggestions :)
Maybe just add a note that the INSTALL example doesn't really conform
to current FHS?

[Klaus Schmidinger]

Post by Steffen Barszus
...

+VIDEODIR = /srv/vdr/video0

...
video0 , because it
allows for easy extension of storage space, without reconfiguring vdr,
video1, video2 and videoX will be used autmatically by vdr at next
start.

Note, though, that after version 2.0 this "multiple disk handling" will
be deprecated and later dropped. So I suggest in a template it should
be /srv/vdr/video, without the '0' at the end.

Klaus

[Manuel Reimer]

Post by Klaus Schmidinger
Note, though, that after version 2.0 this "multiple disk handling" will
be deprecated and later dropped. So I suggest in a template it should
be /srv/vdr/video, without the '0' at the end.

In my opinion, this way a great feature of VDR would be lost. There is *no*
alternative to easily add more space to VDR.

Yours

Manuel

[Klaus Schmidinger]

Post by Manuel Reimer

Post by Klaus Schmidinger
Note, though, that after version 2.0 this "multiple disk handling" will
be deprecated and later dropped. So I suggest in a template it should
be /srv/vdr/video, without the '0' at the end.

In my opinion, this way a great feature of VDR would be lost.

This method may have been useful in the old days where large
harddisks were unavailable or hard to come by. Now we're living
in the age of terabyte disks, and setting up a VDR with 1TB of
video storage (even using a second disk to have a RAID-1 for
data safety) os no big deal any more.

Post by Manuel Reimer
There is *no* alternative to easily add more space to VDR.

Isn't LVM the keyword here?

At any rate, I want to get rid of that symlink stuff and allow
VDR to "see" only one big video directory. Of course there may
still be other volumes mounted on subdirectories of that video
directory.

Klaus

[Manuel Reimer]

Post by Klaus Schmidinger
This method may have been useful in the old days where large
harddisks were unavailable or hard to come by. Now we're living
in the age of terabyte disks, and setting up a VDR with 1TB of
video storage (even using a second disk to have a RAID-1 for
data safety) os no big deal any more.

Especially with HDTV the amount of disc space, used for recordings, also got bigger.

Post by Klaus Schmidinger
Isn't LVM the keyword here?

No. It is virtually impossible to just merge in a second disc if the first already has data on it and hasn't been set up as LVM physical volume on first install.

You would have to move all data to another disc to set up the first VDR disc from scratch with LVM. After setting up, all data has to be copied back. I think it requires several hours to set that up. With the VDR multiple disc feature, I just install the new disc and mount it --> Setup done.

Another big disadvantage of LVM is, that it is nearly impossible to restore data of one of the LVM discs, if only one disc is available. Means: If one disc dies, all recordings are gone.

Post by Klaus Schmidinger
At any rate, I want to get rid of that symlink stuff and allow
VDR to "see" only one big video directory. Of course there may
still be other volumes mounted on subdirectories of that video
directory.

But then I would have to save recordings to those subdirectories on my own and VDR wouldn't even see that additional space. Means: The displayed disc usage would be unusable.

If it causes you trouble to keep that feature, then, of course, you should remove it, but I don't think that it really is obsolete nowadays. It still is the easiest way to add a second disc to a existing VDR installation without needing to move/copy/setup things for several hours.

Yours

Manuel

[Steffen Barszus]

On Sun, 08 Apr 2012 11:54:21 +0200

Post by Manuel Reimer

Post by Klaus Schmidinger
This method may have been useful in the old days where large
harddisks were unavailable or hard to come by. Now we're living
in the age of terabyte disks, and setting up a VDR with 1TB of
video storage (even using a second disk to have a RAID-1 for
data safety) os no big deal any more.

Especially with HDTV the amount of disc space, used for recordings, also got bigger.

Post by Klaus Schmidinger
Isn't LVM the keyword here?

No. It is virtually impossible to just merge in a second disc if the
first already has data on it and hasn't been set up as LVM physical
volume on first install.
You would have to move all data to another disc to set up the first
VDR disc from scratch with LVM. After setting up, all data has to be
copied back. I think it requires several hours to set that up. With
the VDR multiple disc feature, I just install the new disc and mount
it --> Setup done.
Another big disadvantage of LVM is, that it is nearly impossible to
restore data of one of the LVM discs, if only one disc is available.
Means: If one disc dies, all recordings are gone.

Try mhddfs - the only thing it misses from vdr behaviour (if
partition size is chosen well) is to put the small files on another
harddisk, then the bigger files (i.e. put index and info on 00 and
all the rest somewhere else).

Knowing the history of bugs on that part (also, but not only in vdr
core) its a wise choice to drop support for it (i say that even if i'm a
user of that feature and like it a lot !)

[Klaus Schmidinger]

Post by Steffen Barszus
On Sun, 08 Apr 2012 11:54:21 +0200

Post by Manuel Reimer

Post by Klaus Schmidinger
This method may have been useful in the old days where large
harddisks were unavailable or hard to come by. Now we're living
in the age of terabyte disks, and setting up a VDR with 1TB of
video storage (even using a second disk to have a RAID-1 for
data safety) os no big deal any more.

Especially with HDTV the amount of disc space, used for recordings, also got bigger.

Post by Klaus Schmidinger
Isn't LVM the keyword here?

No. It is virtually impossible to just merge in a second disc if the
first already has data on it and hasn't been set up as LVM physical
volume on first install.
You would have to move all data to another disc to set up the first
VDR disc from scratch with LVM. After setting up, all data has to be
copied back. I think it requires several hours to set that up. With
the VDR multiple disc feature, I just install the new disc and mount
it --> Setup done.
Another big disadvantage of LVM is, that it is nearly impossible to
restore data of one of the LVM discs, if only one disc is available.
Means: If one disc dies, all recordings are gone.

Try mhddfs - the only thing it misses from vdr behaviour (if
partition size is chosen well) is to put the small files on another
harddisk, then the bigger files (i.e. put index and info on 00 and
all the rest somewhere else).

Now that sounds like a very good alternative!
I'd say this puts the final nail into this VDR feature's coffin ;-)

Post by Steffen Barszus
Knowing the history of bugs on that part (also, but not only in vdr
core) its a wise choice to drop support for it (i say that even if i'm a
user of that feature and like it a lot !)

Well put ;-)

BTW: let's not hijack this thread any longer (sorry for doing this initially).
This is about the FHS patch, so let's hear ACKs or NACKs for that.

Klaus

[Manuel Reimer]

Post by Klaus Schmidinger

Post by Steffen Barszus
Try mhddfs

Now that sounds like a very good alternative!
I'd say this puts the final nail into this VDR feature's coffin ;-)

ACK. Revoking my vote for the old feature. I hope that mhddfs is well maintained. Seems to be a pretty good alternative. Still a bit work to set up but much easier and has less disadvantages as LVM.

Post by Klaus Schmidinger
BTW: let's not hijack this thread any longer (sorry for doing this initially).
This is about the FHS patch, so let's hear ACKs or NACKs for that.

ACK from me, but without the last additions by Christopher (more complex handling of directory paths based on whether the new parameters to VDR are given).

My primary focus is on the "Resource Directory" but the "Cache Directory" is a nice addition. So far, many plugin developers place resource data in the "Config Directory", just as this directory can easily be retrieved via plugin API.

I agree that, in theory, we would need another directory for "non VDR writable config files" like the svdrphosts.conf file, but I think we should at first take what we have. Future additions are always possible.

Yours

Manuel

[Christopher Reimer]

Post by Manuel Reimer
ACK from me, but without the last additions by Christopher (more complex
handling of directory paths based on whether the new parameters to VDR are
given).

Yes, I also think it's better to not use these additions. It's complex and
I don't see any reason for them. Usually everything which is set in
Make.config is right.

[Gero]

Post by Klaus Schmidinger

Post by Manuel Reimer
In my opinion, this way a great feature of VDR would be lost.

This method may have been useful in the old days where large
harddisks were unavailable or hard to come by. Now we're living
in the age of terabyte disks, and setting up a VDR with 1TB of
video storage (even using a second disk to have a RAID-1 for
data safety) os no big deal any more.

Post by Manuel Reimer
There is *no* alternative to easily add more space to VDR.

Isn't LVM the keyword here?

I agree to Manuel.

The possibility to extend an exhausted video-dir is unique to vdr and all
quirks could be handled by simple scripting - opposed to quirks of lvm or the
like.

The fact that nfs can not handle mounted subfs should be no reason to kill the
vdrs videodir handling.

and beside that: I really love the feature to have splitted files. Even in days
of terabyte drives - I use max filesize of 200 Mb, which has several advantages
for me.

kind regards

Gero

[Udo Richter]

Post by Klaus Schmidinger
At any rate, I want to get rid of that symlink stuff and allow
VDR to "see" only one big video directory.

Sorry for being OT, just wanted to extend my thought of the last
post-2.0-offtopic discussion: Modularize.

Defining an interface for 'video storage' thingys, together with the
ability to have several storages loaded at the same time, would allow to
have plain old /video storage and (maybe as plugin) remote network
storages. It would also allow to have more than one local storage.
(Maybe a storage backend that read/writes AVI or MKV?)
And if the old, ugly symlink system gets dropped, it could even be
continued by a compatibility plugin.

There are tons of more possibilities here, but we should delay that to
post-2.0.


Cheers,

Udo

[Manuel Reimer]

Post by Steffen Barszus
vdr has 2 types of conf files -
1) internal databases - like channels.conf, setup.conf
2) real conf files like scr.conf, diseqc.conf etc
1 should be in /var/lib/vdr
2 should be in /etc/vdr/

I don't think so. VDR has two types of conf files, but they are:

- Files that are editable via OSD
- Files that *should be* editable via OSD

IMHO VDR is the only receiver which requires me to log in via SSH to configure
my DiSEqC settings.

Yours

Manuel

[Gero]

Post by Manuel Reimer

Post by Steffen Barszus
vdr has 2 types of conf files -
1) internal databases - like channels.conf, setup.conf
2) real conf files like scr.conf, diseqc.conf etc

- Files that are editable via OSD
- Files that *should be* editable via OSD

Well, then the vdr has a third category of conf files:

- Files, that are written without user interaction

and such files are *definitely* *not* config-files, even if they have conf-
extension. Some folks called such conf-files databases.
Handle the writing of conf-files by user interaction (OSD or replacements)
could be wrapped by a write-enablement-script or function, so config-files could
stil reside on RO-media.

From my point of understanding, the FHS discussion is not focused on the
config-files, that could not be managed by OSD, but is focused on the point,
when config-files are written.

kind regards

Gero