Re: [vdr] Filesystem hierachy standard patch needs review.
On Saturday 07 April 2012 - 08:43:40, VDR User wrote: > 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 2012-04-07 04:05, schrieb VDR User: On Fri, Apr 6, 2012 at 11:25 AM, Gero wrote: 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
[ ... 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.27
On 06.04.2012 22:13, Juergen Lock wrote:
In article<4f6f0570.7050...@tvdr.de> you write:
VDR developer version 1.7.27 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.27.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.26-1.7.27.diff
[...]
Hi!
While upgrading from 1.7.22 to 1.7.27 I noticed epg scans on a
single tuner (with xineliboutput in this case) no longer seem to
happen while that tuner is in live view mode, even trying to force
a scan via the osd or via "svdrpsend scan" no longer does anything.
Am I right this is because eitscan.c cEITScanner::Process does
...
if (!Device->Receiving()) {
...
and device.c cDevice::Receiving's bool arg no longer does anything
i.e. it no longer checks the attached receiver's priorities and thus
returns true even for devices only in live view mode?
And if yes, what would be the proper fix? :)
Please try changing
if (!Device->Receiving()) {
to
if (Device->Priority() < 0) {
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 06.04.2012 15:01, schrieb 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/7 Udo Richter > Am 06.04.2012 15:01, schrieb 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: > > 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 vdr_fhs_1.3.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.27
On Sat, Apr 07, 2012 at 11:39:38AM +0200, Klaus Schmidinger wrote:
> On 06.04.2012 22:13, Juergen Lock wrote:
> > In article<4f6f0570.7050...@tvdr.de> you write:
> >> VDR developer version 1.7.27 is now available at
> >>
> >>ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.27.tar.bz2
> >>
> >> A 'diff' against the previous version is available at
> >>
> >>ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.26-1.7.27.diff
> >>
> >> [...]
> >
> > Hi!
> >
> > While upgrading from 1.7.22 to 1.7.27 I noticed epg scans on a
> > single tuner (with xineliboutput in this case) no longer seem to
> > happen while that tuner is in live view mode, even trying to force
> > a scan via the osd or via "svdrpsend scan" no longer does anything.
> >
> > Am I right this is because eitscan.c cEITScanner::Process does
> >
> > ...
> > if (!Device->Receiving()) {
> > ...
> >
> > and device.c cDevice::Receiving's bool arg no longer does anything
> > i.e. it no longer checks the attached receiver's priorities and thus
> > returns true even for devices only in live view mode?
> >
> > And if yes, what would be the proper fix? :)
>
> Please try changing
>
> if (!Device->Receiving()) {
>
> to
>
> if (Device->Priority() < 0) {
>
>
Yep, that fixes it, now "svdrpsend scan" works again.
Thanx! :)
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
> 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.
A couple of comments regarding the INSTALL part:
06.04.2012 16:01, Christopher Reimer kirjoitti:
> +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?
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Sat, 07 Apr 2012 19:24:17 +0300
Anssi Hannula wrote:
> > 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.
>
> A couple of comments regarding the INSTALL part:
>
> 06.04.2012 16:01, Christopher Reimer kirjoitti:
> > +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).
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.
>
> > +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.
> 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?
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 07.04.2012 20:03, Steffen Barszus wrote: ... +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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
