Re: [vdr] Filesystem hierachy standard patch needs review.
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 think they belong to /etc to make sure they are included in backups by default. FHS says about /etc: The /etc hierarchy contains configuration files. A configuration file is a local file used to control the operation of a program; it must be static and cannot be an executable binary. Keep you eyes on it must be static! You could learn from debian systems, where the stuff in /etc is really static. Even with vdr. 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 static and non-static configuration, but it obeys the rules. See http://wiki.debian.org/ReadonlyRoot for advantages of that aproach. Regarding backup: If you allow your backup application to follow links and save the original, the databases will be saved. But even better: Teach your SUSE-users to save /var/lib I believe, from backup point of view, /var/lib has the same or even higher importance to get saved, than /etc 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 recordings like a NAS or MediaServer, so in case the VDR is a backend machine, it might be better to symlink /var/spool/video to /srv/video or the like. kind regards Gero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
Tobi listacco...@e-tobi.net writes: On 12.08.2012 14:32, Klaus Schmidinger wrote: Do you actually *have* a remote control with non-standard color keys? I use an UR-2400 - R/Y/B/G. ...but I got used to it. Same here, RYBG. I'll give the patch a try this evening. Thanks -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/9/4 Gero geronimo...@gmx.de: 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 recordings like a NAS or MediaServer, so in case the VDR is a backend machine, it might be better to symlink /var/spool/video to /srv/video or the like. The FHS gives further examples for /var/spool Printer spool directory Outgoing mail queue I cannot see how a recording directory is comparable with a printer or outgoing mail queue. Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR File splitting validation
Dear all, We are using vdr (1.7.21) to record from a DVB-T2 stream. File split quota is at 200MB. The broadcast stream comes with audio packets (data) roughly 2 seconds after then the video packets. They are in perfect time stamp sync (video-audio). It is just the data packets that are late in the data stream). Now, when VDR does the file split (after the quota has been met and a video I-Frame is about to start) the audio packets that would be in sync with the latest video frames before the split are actually being contained in the next split file. This creates me big extra workload, I want to be able to process the split files individually, but I cannot since they don't have audio-video integrity. What would it take to make vdr splitting smarter in this case, that is to only split the files after all the significant audio packets have been received as well? Thanks for your attention, Rares -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Tue, Sep 4, 2012 at 12:38 AM, Ludwig Nussel ludwig.nus...@suse.de 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 configuration like the ordering of stations. Why would you assume single timer recordings, or any recordings at all are short-lived? If anything users tend to record shows and watch them at some point in the non-immediate future -- the weekend for example, when they're more likely to have time sitting around watching tv. I know several people who record entire series and don't even start watching them until all the episodes are recorded so they don't have the irritating wait of a week+ between them. Then there are houses, like mine, where one person will watch a recording one day, then somebody else will watch the same thing some days later. By now you should get the point that assuming recordings are short-lived is bad, automatically deleting them is bad, etc. Typical user behavior from my observation certainly isn't record something, watch it immediately, then delete it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 static and non-static configuration, but it obeys the rules. See http://wiki.debian.org/ReadonlyRoot for advantages of that aproach. It's useless to separate between static and non-static configuration files in VDR, as in my opinion, VDR doesn't really have files that should be static. 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, still required, using his remote control. 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. Just place them all to /var/lib/vdr and you are done. Lots of VDR-users use VDR as a standalone system and for those systems /var/spool might be more appropriate than /srv /var/spool is definitively wrong, as this applies to queue-like things. /srv is right, if the VDR-machine offers the recordings like a NAS or MediaServer, FHS says: | /srv : Data for services provided by this system So as VDR is the primary service of such a box, /srv seems to be OK for me. And many distributions share the recordings via FTP or Samba anyways. For me the discussion about the default setting seems to be useless. The current default seems to match the FHS definitions pretty well and any distribution is able to easily add own settings via make parameters or via Make.config. So feel free to override the default and use your own settings. The main topic in this sub-thread is testing the new patch, which will add API functions for the plugins for the first time, allowing plugins to place their resources to wherever the distributor decided to put them. No longer abuse of ConfigDirectory for static resources! No more plugin patching! No more ugly symlinks between /var/lib/vdr/... and /usr/share/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.
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 ordering of stations. So you talk about timers.conf and channels.conf? They are both dynamic in the same way. VDR heavily modifies channels.conf. Names, PIDs, are modified and even new channels are added completely automatically! If I move channels, add channels, ... via OSD, then VDR also modifies this file to store my changes. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR File splitting validation
Am 04.09.2012 15:22, schrieb Rares Pop: Now, when VDR does the file split (after the quota has been met and a video I-Frame is about to start) the audio packets that would be in sync with the latest video frames before the split are actually being contained in the next split file. Thats because VDR does splitting and editing on the data stream level, not on the audio/video-track level. Merging all the file pieces together always gives the original stream, with just very minor modifications. Editing based on time stamps would be a lot more difficult, as near the splitting point, data needs to be moved to the previous/next file, depending on whether audio is ahead/behind video. To make things more complicated, there's no guarantee that together with the I-frame also a new audio frame starts at the exact time stamp. For precise editing, an audio frame may have to be split and re-compressed. And for playback, the same applies in reverse: For pre-buffering, the A/V-data of the file end and beginning needs to be merged with proper offset again. This is all a lot more complicated than just splitting the whole data stream as one. For further processing, its the best to merge continuous stream parts into one big file, if the program cannot handle split files on its own. If you want to avoid the copying, take a look at vdrnfofs, a virtual file system that virtually merges VDR recordings into single mpg files. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
