Re: [vdr] Filesystem hierachy standard patch needs review.
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 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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* alternative to easily add more space to VDR. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 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. 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 no big deal any more. Especially with HDTV the amount of disc space, used for recordings, also got bigger. 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. 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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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: - 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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'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. 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Sun, 08 Apr 2012 11:54:21 +0200 Manuel Reimer manuel.rei...@gmx.de 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 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. 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 !) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 08.04.2012 12:45, Steffen Barszus wrote: On Sun, 08 Apr 2012 11:54:21 +0200 Manuel Reimermanuel.rei...@gmx.de 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 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. 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 ;-) 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 work to set up but much easier and has less disadvantages as LVM. 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 -- () ascii ribbon campaign - against html mail /\- gegen HTML-Mail answers as html mail will be deleted automatically! Antworten als HTML-Mail werden automatisch gelöscht! Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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/8 Manuel Reimer manuel.rei...@gmx.de 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
Hi,
I located a small bug which has been introduced in 1.7.18 (at least I think
so). Reading the Changes file I could not determine which change caused it,
but the problem is the following.
In pat.c: if the PMT of a service has a stream of stream-type 128 (0x80)
the vpid is overridden with the PID signalled in the Elementary-PID-field of
this stream. This happens to be the case here in France for some of the DVB-
T services. It breaks 2 channels (France 2 and France 5) when channel-
updates is at least configured to update PIDs.
The code which is doing that is described as STREAMTYPE_USER_PRIVATE -
DigiCipher II VIDEO (ANSI/SCTE 57) which before was only applied when the
stream had a certain descriptor and there a certain type.
The attached patch resets the code to do exactly that for STREAMTYPE 0x80 -
though can't check whether the digiCipher-stuff is still working.
Please consider applying soon.
Thanks,
--
Patrick
http://www.kernellabs.com/
diff --git a/pat.c b/pat.c
index d9b93f6..f0d0024 100644
--- a/pat.c
+++ b/pat.c
@@ -456,12 +456,30 @@ void cPatFilter::Process(u_short Pid, u_char Tid, const u_char *Data, int Length
}
}
break;
- case 0x80: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
- Vpid = esPid;
- Ppid = pmt.getPCRPid();
- Vtype = 0x02; // compression based upon MPEG-2
- ProcessCaDescriptors = true;
- break;
+ case 0x80: {
+ SI::Descriptor *d;
+ for (SI::Loop::Iterator it; (d = stream.streamDescriptors.getNext(it)); ) {
+ switch (d-getDescriptorTag()) {
+ case SI::RegistrationDescriptorTag: {
+ SI::RegistrationDescriptor *rd = (SI::RegistrationDescriptor *)d;
+ // http://www.smpte-ra.org/mpegreg/mpegreg.html
+ switch (rd-getFormatIdentifier()) {
+ case 0x44434949: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
+ Vpid = esPid;
+ Ppid = pmt.getPCRPid();
+ Vtype = 0x02; // compression based upon MPEG-2
+ ProcessCaDescriptors = true;
+ break;
+ default:
+ break;
+ }
+ } break;
+ default:
+ break;
+ }
+ }
+ } break;
+
case 0x81: // STREAMTYPE_USER_PRIVATE - ATSC A/53 AUDIO (ANSI/SCTE 57)
{
char lang[MAXLANGCODE1] = { 0 };
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 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
diff -ruN vdr-1.7.27/INSTALL vdr-1.7.27.patched//INSTALL
--- vdr-1.7.27/INSTALL 2012-02-27 12:03:14.0 +0100
+++ vdr-1.7.27.patched//INSTALL 2012-04-06 09:43:38.590832504 +0200
@@ -375,6 +375,18 @@
VDR archive into your video directory (or into your config directory,
respectively, in case you have redirected it with the -c option).
+If you prefer to have your system set up according to the FHS
+(File system Hierarchy Standard) and thus have all your files spread
+around the entire file system, you can do this by adding a Make.config
+file with the following settings
+
+CACHEDIR = /var/cache/vdr
+CONFDIR = /var/lib/vdr
+LOCDIR = $(PREFIX)/share/locale
+PLUGINLIBDIR = $(PREFIX)/lib/vdr
+RESDIR = $(PREFIX)/share/vdr
+VIDEODIR = /srv/vdr/video0
+
Setting up DiSEqC:
--
diff -ruN vdr-1.7.27/Make.config.template vdr-1.7.27.patched//Make.config.template
--- vdr-1.7.27/Make.config.template 2012-03-20 12:20:13.0 +0100
+++ vdr-1.7.27.patched//Make.config.template 2012-04-06 09:43:38.591832504 +0200
@@ -33,6 +33,8 @@
PLUGINLIBDIR = $(PLUGINDIR)/lib
VIDEODIR = /video
CONFDIR = $(VIDEODIR)
+#CACHEDIR = $(VIDEODIR)
+#RESDIR = $(CONFDIR)
### The remote control:
diff -ruN vdr-1.7.27/Makefile vdr-1.7.27.patched//Makefile
--- vdr-1.7.27/Makefile 2012-03-11 16:33:57.0 +0100
+++ vdr-1.7.27.patched//Makefile 2012-04-06 10:06:28.004832504 +0200
@@ -29,6 +29,8 @@
VIDEODIR = /video
CONFDIR = $(VIDEODIR)
+#CACHEDIR = $(VIDEODIR)
+#RESDIR = $(CONFDIR)
DOXYGEN ?= /usr/bin/doxygen
DOXYFILE = Doxyfile
@@ -71,6 +73,8 @@
DEFINES += -DVIDEODIR=\$(VIDEODIR)\
DEFINES += -DCONFDIR=\$(CONFDIR)\
DEFINES += -DPLUGINDIR=\$(PLUGINLIBDIR)\
+DEFINES += -DCACHEDIR=\$(CACHEDIR)\
+DEFINES += -DRESDIR=\$(RESDIR)\
DEFINES += -DLOCDIR=\$(LOCDIR)\
# The version numbers of VDR and the plugin API (taken from VDR's config.h):
@@ -112,6 +116,8 @@
@echo configdir=$(CONFDIR) $@
@echo videodir=$(VIDEODIR) $@
@echo plugindir=$(PLUGINLIBDIR) $@
+ @echo cachedir=$(CACHEDIR) $@
+ @echo resdir=$(RESDIR) $@
@echo localedir=$(LOCDIR) $@
@echo apiversion=$(APIVERSION) $@
@echo cflags=$(CXXFLAGS) $(DEFINES) -I\$${includedir} $@
@@ -183,7 +189,7 @@
# Install the files:
-install: install-bin install-conf install-doc install-plugins install-i18n install-includes install-pc
+install: install-bin install-dirs install-conf install-doc install-plugins install-i18n install-includes install-pc
# VDR binary:
@@ -193,12 +199,15 @@
# Configuration files:
-install-conf:
+install-dirs:
@mkdir -p $(DESTDIR)$(VIDEODIR)
- @if [ ! -d $(DESTDIR)$(CONFDIR) ]; then\
- mkdir -p $(DESTDIR)$(CONFDIR);\
- cp *.conf $(DESTDIR)$(CONFDIR);\
- fi
+ @mkdir -p $(DESTDIR)$(CONFDIR)
+ @mkdir -p $(DESTDIR)$(RESDIR)
+ @mkdir -p $(DESTDIR)$(CACHEDIR)
+
+install-conf:
+ @cp *.conf $(DESTDIR)$(CONFDIR)
+
# Documentation:
diff -ruN vdr-1.7.27/PLUGINS.html vdr-1.7.27.patched//PLUGINS.html
--- vdr-1.7.27/PLUGINS.html 2012-03-09 10:49:29.0 +0100
+++ vdr-1.7.27.patched//PLUGINS.html 2012-04-06 09:43:38.594832504 +0200
@@ -82,7 +82,7 @@
lia href=#WakeupWakeup/a
lia href=#Setup parametersSetup parameters/a
lia href=#The Setup menuThe Setup menu/a
-lia href=#Configuration filesConfiguration files/a
+lia href=#Additional filesAdditional files/a
lia href=#InternationalizationInternationalization/a
lia href=#Custom servicesCustom services/a
lia href=#SVDRP commandsSVDRP commands/a
@@ -885,39 +885,55 @@
your setup parameters and use that one to copy all parameters with one single statement
(like VDR does with its cSetup class).
-hrh2a name=Configuration filesConfiguration files/a/h2
+hrh2a name=Additional filesAdditional files/a/h2
div class=blurbI want my own stuff!/divp
-There may be situations where a plugin requires configuration files of its own, maybe
-for data that can't be stored in the simple a href=#Setup parameterssetup parameters/a
-of VDR, or maybe because it needs to launch other programs that simply need a separate
-configuration file. While the plugin is free to store such files anywhere it
-sees fit, it might be a good idea to put them in a common place, preferably
-where other configuration data already exists. VDR provides the function
+There may be situations where a plugin requires own
Re: [vdr] OT: video dir symlink [WAS:Filesystem hierachy standard patch needs review.]
Am 08.04.2012 11:36, schrieb 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 ___ 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/8 Udo Richter udo_rich...@gmx.de - 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Sun, Apr 8, 2012 at 10:57 AM, Christopher Reimer c.reimer1...@googlemail.com 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 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 ___ 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/8 VDR User 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, although I don't understand why. Let's wait what Klaus says. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Sun, Apr 8, 2012 at 2:11 PM, Christopher Reimer c.reimer1...@googlemail.com wrote: 2012/4/8 VDR User 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, 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
