On 07.09.2012 13:26, Klaus Schmidinger wrote:
On 07.09.2012 13:04, Christopher Reimer wrote:
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30
On 07.09.2012 13:04, Christopher Reimer wrote:
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30.
Didn't try it, so far, but I had a look at
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a
small problem:
+# By
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small
problem:
+# By default VDR requires only one single directory
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small
problem:
+# By default VDR requires only one single directory to operate:
VIDEODIR = /video
-CONFDIR =
Ludwig Nussel wrote:
I'd still consider a file that is only modified if the user
intentionally does so via the remote control static. There's no
difference between that and using an editor except for the user
interface.
The difference is, that /etc is mounted readonly on some distributions (lik
2012/9/6 Ludwig Nussel :
> Manuel Reimer wrote:
>> So for me it seems to be useless to try to strictly separate VDR's
>> configuration files between "static" and "dynamic". They all should be
>> dynamic and maybe at any time they could get dynamic, if Klaus
>> improves the OSD setup possibilities.
Manuel Reimer wrote:
> So for me it seems to be useless to try to strictly separate VDR's
> configuration files between "static" and "dynamic". They all should be
> dynamic and maybe at any time they could get dynamic, if Klaus
> improves the OSD setup possibilities.
I'd still consider a file that
On 04.09.2012 22:29, Manuel Reimer wrote:
...
For example the file "diseqc.conf" should be editable via OSD, in my opinion.
If I pre-setup an VDR system for someone, then it should be possible to just hand over
the system to him and he should be able to just connect the wires and do anything, s
Ludwig Nussel wrote:
[Readonly /etc]
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 orderi
Gero wrote:
Vdr's databases reside in /var/lib/vdr where they are changeable by intention.
The databases are linked to /etc.
So the content from /etc (the links to vdr-databases) is static, but the
content of the databases is not.
Its not that good as if the vdr would have divided the setup into
On Tue, Sep 4, 2012 at 12:38 AM, Ludwig Nussel wrote:
> 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 confi
2012/9/4 Gero :
>> I decided to use /var/spool/video (could have been /var/spool/vdr
>> too).
>
> That's a good point!
>
> Lots of VDR-users use VDR as a standalone system and for those systems
> /var/spool might be more appropriate than /srv
>
> /srv is right, if the VDR-machine offers the recordi
On Monday 03 September 2012 - 15:42:04, Ludwig Nussel wrote:
> So nine years ago when I started packaging vdr for SUSE ...
Sorry, but Suse is not known for doing things right :(
... and they don't care much about system quality.
> Even though vdr may update some of the files there itself I still
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.
>>
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 discussi
On 03.09.2012 15:42, Ludwig Nussel wrote:
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 discu
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
orig
2012/9/1 Klaus Schmidinger :
> Please try it and let me know if it works as expected.
I have patched my vdr and I cannot see any problems with this changes.
I works with and without USE_FHS=1 as expected.
___
vdr mailing list
vdr@linuxtv.org
http://www
On 09.05.2012 16:36, Manuel Reimer wrote:
Hello,
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.
Please try it and let me know if it works as expected.
Klaus
diff -u -b -r2.13 ./INSTALL
-
Hello,
what is the current status in this topic? Anyone working on this?
Yours
Manuel
Klaus Schmidinger wrote:
On 09.04.2012 15:18, Udo Richter wrote:
Am 09.04.2012 11:54, schrieb Klaus Schmidinger:
However, there is one thing in the current behavior that I would even
consider a bug: if one
On 09.04.2012 15:18, Udo Richter wrote:
Am 09.04.2012 11:54, schrieb 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
configurati
Am 09.04.2012 11:54, schrieb 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 lo
On 09.04.2012 13:44, Pertti Kosunen wrote:
On 9.4.2012 14:19, Klaus Schmidinger wrote:
What "./configure"???
When compiling VDR from source, "./configure ; make ; make install".
There is no "./configure" in the VDR source.
Klaus
___
vdr mailing l
On 9.4.2012 14:19, Klaus Schmidinger wrote:
What "./configure"???
When compiling VDR from source, "./configure ; make ; make install".
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 09.04.2012 13:15, Pertti Kosunen wrote:
On 9.4.2012 12:54, Klaus Schmidinger wrote:
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'
On 9.4.2012 12:54, Klaus Schmidinger wrote:
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 fol
2012/4/9 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 exp
Udo Richter wrote:
> 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 stri
On 08.04.2012 23:11, Christopher Reimer wrote:
2012/4/8 VDR User mailto:user@gmail.com>>
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, alt
On Sun, Apr 8, 2012 at 2:11 PM, Christopher Reimer
wrote:
> 2012/4/8 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
2012/4/8 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.
__
On Sun, Apr 8, 2012 at 10:57 AM, Christopher Reimer
wrote:
>> - 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 y
2012/4/8 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 w
Am 08.04.2012 09:48, schrieb 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
2012/4/8 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.
Klaus Schmidinger wrote:
> > 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 wor
On 08.04.2012 12:45, Steffen Barszus wrote:
On Sun, 08 Apr 2012 11:54:21 +0200
"Manuel Reimer" wrote:
Klaus Schmidinger wrote:
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
On Sun, 08 Apr 2012 11:54:21 +0200
"Manuel Reimer" wrote:
> Klaus Schmidinger wrote:
> > 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 st
On Sunday 08 April 2012 - 11:36:18, Klaus Schmidinger wrote:
> On 08.04.2012 09:51, Manuel Reimer wrote:
> >
> > 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'r
On Sunday 08 April 2012 - 09:54:52, Manuel Reimer wrote:
> Steffen Barszus wrote:
> > 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
>
> I don't think so. VDR has two types of conf files, but they are
Klaus Schmidinger wrote:
> 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
On 08.04.2012 09:51, Manuel Reimer wrote:
Klaus Schmidinger wrote:
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 featur
Steffen Barszus wrote:
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 ar
Klaus Schmidinger wrote:
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*
alte
Udo Richter wrote:
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 the
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 "mu
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, Christop
> 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/
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
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.co
[ ... 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
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 poi
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
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, avail
On Fri, Apr 6, 2012 at 9:50 PM, Gero wrote:
>> 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
On Saturday 07 April 2012 - 04:05:16, VDR User wrote:
> 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 f
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
On Friday 06 April 2012 - 18:07:55, Klaus Schmidinger wrote:
> On 06.04.2012 17:06, Gero wrote:
> > 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 ha
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
On 06.04.2012 17:06, Gero wrote:
Hi,
On Friday 06 April 2012 - 15:01:14, Christopher Reimer wrote:
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
Hi,
On Friday 06 April 2012 - 15:01:14, Christopher Reimer wrote:
> 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
62 matches
Mail list logo
