Re: [vdr] vdr-xine breakage with Freeview HD
On 2012-09-07 03:28, Darren Salt wrote: I've noticed audio brokenness with vdr-xine 0.9.4 and (at least) the BBC channels on Freeview HD. Recordings are fine and are played back without problem if played directly rather than via vdr. There's a sample recording (tarball, with b0rked filename due to the lack of decoding in stock Debian vdr) at http://tartarus.org/ds/bbchdvdr.tar (file size is 84172800 bytes; still being uploaded when I sent this). By 'played back ... directly' do you mean played back with xine, too, or with another player? I used to have loads of problems with xine and AAC LATM encoded audio on my VDR rig, and mplayer tells me that your BBC recordings uses exactly that format: ... Playing 2012-09-07.02.07.54-0.rec/1.ts. libavformat version 54.1.100 (internal) TS file format detected. VIDEO H264(pid=101) AUDIO AAC LATM(pid=102) SUB DVB(pid=105) PROGRAM N. 132 AFAICT support for LATM audio was only added in xinelib-1.1.19 and later: http://old.nabble.com/-PATCH--Add-AAC-LATM-support-from-FFmpeg-0.7%2B-td32355161.html The LATM channels finally started working here when I upgraded to VDR+xineliboutput from the yavdr unstable packages. My install is a bit dated but I suppose it works with more recent versions than these, too: ii libavcodec534:0.7.6-0ubuntu0.11.10. Libav codec library ii libxine21.2.1.hg20120511.1541-0 the xine video/media player library, binary files ii vdr 1.7.22-2yavdr1~oneiric Video Disk Recorder for DVB cards ii vdr-plugin-xineliboutpu 1.0.7+cvs20120511.1602- VDR plugin for Xine based sofdevice frontends ii xine-ui 0.99.7~hg20120217-0yavd the xine video player, user interface Additionally I just tested that your recording plays with audio when played directly in xine on my LMDE (Debian Testing based) laptop with the following packages: ii libavcodec53 5:0.10-0.1 Library to encode decode multimedia streams - runtime files. ii libxine2 1:1.2.1-0.1 Xine media player library, meta-package (development branch). ii xine-ui 0.99.7~hg20120125-1 the xine video player, user interface So perhaps you need a more recent xine/libav combo. Cheers, Jonas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xine breakage with Freeview HD
I've noticed audio brokenness with vdr-xine 0.9.4 and (at least) the BBC channels on Freeview HD. Recordings are fine and are played back without problem if played directly rather than via vdr. There's a sample recording (tarball, with b0rked filename due to the lack of decoding in stock Debian vdr) at http://tartarus.org/ds/bbchdvdr.tar (file size is 84172800 bytes; still being uploaded when I sent this). -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Confucius say: He who post in HTML, get flamed. ___ 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:
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 = $(VIDEODIR)
+# See Make.config.template if you want to build VDR according to the FHS ("File
system Hierarchy Standard")
[...]
+
+install-conf:
+ @cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is *not* used,
as "CONFDIR" is not defined without the FHS mode enabled?
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: 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 (like Debian)! This is OK if you only do changes in very rare cases. In this cases, you just remount /etc with writing enabled for that short time. This doesn't work with VDR. Especially as there doesn't have to be user interaction for the files to be modified. VDR changes channels.conf pretty often even without the user knowing about that. If you use "epgsearch", then "timers.conf" is modified regularly depending on the channels EPG data, ... This is why such stuff should go below /var/lib. /srv in theory is taboo for distros (and it is in fact for Fedora) so distros will be forced to patch vdr to use something else. No need to patch anything. Just prepare your own "Make.config" and place into the source directory before you start building VDR. It's fine to use for a self compiled vdr but it's not for a distro package. I searched the web and for me it seems like even OpenSuSE uses /srv/www to store the "service relevant" data for the Apache webserver. So why is this OK for Apache but bad for VDR? VDR does not *install* files to the VIDEODIR, by default. It just uses it to store recordings. 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.
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. > > 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. > >>> 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. > > Well, that's your opinion. > It's also my opinion. And the opinion of many others e.g. yaVDR Maintainers. OK timeshift recordings could be saved to /var/spool, but for most people the recording directory is more like an archive. >>> /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 > > /srv in theory is taboo for distros (and it is in fact for Fedora) > so distros will be forced to patch vdr to use something else. It's > fine to use for a self compiled vdr but it's not for a distro > package. I maintain build scripts for Archlinux (No, not ArchVDR) and there it's only "taboo" to install files there. A good example in Archlinux is httpd, nothing is installed to /srv but httpd is configured to search for website data there. > >> 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. > > We are forced to do that already anyways. If vdr changes anything wrt > fs layout I'd really like to see something acceptable for distros to > end the ranting about the different locations of /video. > > Where are the vdr package maintainers of other distros hiding anyways? > There is a thread about FHS in the German forum VDR-Portal (http://www.vdr-portal.de/board60-linux/board14-betriebssystem/65-vdr-verzeichnisse-nach-filesystem-hierarchy-standard-fhs-richtig-ablegen/) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
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 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. >> 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. Well, that's your opinion. >> /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 /srv in theory is taboo for distros (and it is in fact for Fedora) so distros will be forced to patch vdr to use something else. It's fine to use for a self compiled vdr but it's not for a distro package. > 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. We are forced to do that already anyways. If vdr changes anything wrt fs layout I'd really like to see something acceptable for distros to end the ranting about the different locations of /video. Where are the vdr package maintainers of other distros hiding anyways? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
