some vdr intro/installation notes (watch/record/stream tv)

[Juergen Lock]

On Sat, Mar 26, 2011 at 02:55:12PM -0700, VDR User wrote:
> There are a few things I'd like to comment on.....
> 
> On Sat, Mar 26, 2011 at 12:28 PM, Juergen Lock <nox at jelal.kn-bremen.de> wrote:
> >  So what is vdr?  It's something like a luxury settop box/pvr on a pc
> > to receive/watch/record/stream digital tv channels with epg (electronic
> > program guide), timers, client/server networking, webinterface etc pp.
> > So if you have a FreeBSD (or Linux, but that's not covered here :)
> > server you can add one or more dvb/atsc tuner(s) connected to a
> > satellite dish, cable tv or just a dvb-t antenna (or receive iptv
> > streams without a tuner if your isp provides those tho I don't know
> > if anyone tested `real' iptv on FreeBSD yet), browse/search epg,
> > set timers for automated or manual recordings, and watch the
> > streams/recordings elsewhere on your lan.  Or if you have a FreeBSD
> > desktop you can also connect a tuner there and do it all on one
> > box - or just run a vdr client like vdr-sxfe (installed by the
> > multimedia/vdr-plugin-xineliboutput port) or a client vdr instance
> > using the streamdev-client plugin connected to a (possibly Linux)
> > vdr server elsewhere on your lan.
> 
> It should be noted that VDR was not designed to be a server/client
> system.  While it's technically possible to use it that way, keep in
> mind that each client will not have it's own access to OSD, timers,
> etc.  Although server/client systems are widely popular these days, I
> wouldn't expect this kind of major change to happen to VDR any time
> soon.  When and if it ever does, it's going to take a lot of work.
> Unfortunately I don't recall VDR's author (Klaus Schmidinger) ever
> expressing interest in this.
> 
Hm well yeah it could still be better but what is there is not soo bad.

> >  Note: vdr 1.7.17 is the development branch so expect bugs!
> > (I mostly used it because the stable branch (1.6) doesn't support
> > dvb-s2 and h264...)
> 
> There are patches for the latest "stable" branch (1.6.x) which add
> support for dvb-s2 and h264.  The 1.6.x was considered final a long
> time ago and hasn't/won't receive any updates.  All development is
> done in the current 1.7.x branch.  Although VDR has both a "stable"
> and "developer" branch, users should be aware that the developer
> branch is easily as stable as the stable branch.  It's by far the
> users preferred branch of choice.  Nobody should have any worries
> about running a developer version.  The only time I personally run the
> stable branch is inbetween the closure of the last developer branch
> and beginning of the next.  In other words, I've always ran the newest
> version and in all the years of doing this, I can count on one finger
> how many times there was a stability issue.
> 
 Well thats even better then. :)  (I also had few issues.)

> > 1. Before you start installing these ports either mount an extra
> >   fs with enough space for the recordings on /video or create a
> >   video dir elsewhere where there is space, symlink it to /video
> >   and make it writable for the vdr user.  (or if you do have one
> >   big / then you can create the dir on there too of course, I just
> >   disabled the mkdir in the port to avoid inadvertently filling
> >   up ppl's small / fs.)
> >
> >   Or if you don't like a symlink you can also add your video dir
> >   as -v <dir> to vdr's startup args, see below.
> 
> You can create the default dirs and using them directly, use symlinks
> to map the default dirs to dirs elsewhere, remap the defaults by
> editing Makefile, or simply override the defaults using command line
> options as you've mentioned.  I've set my system up so everything
> VDR/dvb-related goes into /dvb.  This makes it very convenient and
> easy to maintain and archive.  Additionally I make use of symlinks
> such as /vdr which is always linked to the latest VDR version,
> /pluginsrc which always takes me to /vdr/PLUGINS/src, and so on.  If
> you're a run-and-forget user then it may not matter much but if you
> tinker a lot then you might consider a similar setup -- you'll have a
> much easier time navigating around the dirs.
> 
 Well I tried to at least somewhat adhere to hier(7)...

> > 3. I have rc.d scripts for vdr and vdradmin-am but even if you
> >   use those you still need to add plugins and their options similar
> >   to this to your /etc/rc.conf:
> 
> You can automate most of the stuff required to run VDR, and everything
> else can be put in a .conf somewhere for the stuff that can't.  I've
> found this extremely useful and worth looking into for any level user.
> 
 Well passing plugin args is automated on Linux often but I didn't
try to port those scripts, wanted to keep things simple...  (editing
rc.conf I think is easy enough?)

> > 4. Of all the video output methods only xineliboutput and streamdev
> >   seem to work (and the vdr-live webinterface browser streaming which
> >   also uses streamdev), jpulz also has patches for softdevice so I made
> >   a port for that too but it only gave me a black screen...  streamdev
> >   doesn't have an osd so you probably want xineliboutput at least for
> >   the first setup.
> 
> Users also have the option of using vdr-xine, which is an alternative
> to xineliboutput.  I'm only aware of a few differences between them,
> none of which have any real significance to me but the vdr-xine
> author, Reinhard Nissl, is an active developer of xine-lib's vdpau
> support as well.  I've never used xineliboutput myself because of
> Rnissl's accessibility and status as a xine-lib vdpau contributor.
> The user bases for both vdr-xine and xineliboutput seem to be pretty
> evenly matched from what I've seen.
> 
 I actually tried to port vdr-xine too more out of curiosity but
only got netvdr:// `working' at all, and it was a slow slideshow.
Probably some linuxism that I missed...  Yeah I should shar that up
so others can take a look.

 Ok just did:

	http://people.freebsd.org/~nox/dvb/xine/vdr-plugin-xine-slideshow.shar

> >   I only very recently was able to test xineliboutput's vdpau/vaapi
> >   support and it turned out I had to add patches to the libxine
> >   port, so if you want to use that make sure it and ffmpeg are up
> >   to date and built with the VDPAU and VAAPI knobs on.  To test
> >   vdpau you can try something like: (vdr-sxfe gets installed by
> >   the xineliboutput plugin port)
> 
> With vdr-xine no patching is necessary as long as you using
> xine-lib-1.2 hg revision 11658 (hash 3501e0a6f75c) or newer.  I
> recommend using this regardless as it contains items necessary for
> VDR-1.7.17's new truecolor OSD support.
> 
 So xine-lib 1.2 is recommendable yet?  I was so far trying to stick
to 1.1.19 release + patches since other FreeBSD ports use libxine
too and I know nothing at all about the 1.2 branch and how stable
it is... :)

> >        vdr-sxfe --hotkeys --video=vdpau --post tvtime:method=use_vo_driver,use_progressive_frame_flag=1 --audio=oss --reconnect xvdr+tcp://127.1
> >
> >   if that looks jerky or doesn't work with hd material maybe your
> >   card cannot handle the default vdpau deinterlacing method, you
> >   can change that in ~/.xine/config_xineliboutput, for an `old'
> >   ION I use:
> >
> >        video.output.vdpau_deinterlace_method:half temporal
> 
> Your ion1 should be able to handle temporal, as mine does.  Using half
> temporal shouldn't be necessary.
> 
 Ok I should check that.

 Hmm no, a 1080i recording of `Servus TV Hockey night' I did for
testing deinterlacing looks `jumpy' with temporal when there is
more motion.  Maybe things have improved in libxine 1.2?

> >   If you don't use vdpau (I think that conflicts with compositing)
> >   you can now also try compositing and running vdr-sxfe with --hud
> 
> IIRC, the compositing issue was resolved some nvidia driver versions
> ago.  You may want to confirm this however at: www.nvnews.net
> 
 Oh, well I think I only got a black window when I tried --hud,
guess I should look again.  (Atm I disabled compositing because
it interfered with hd video playback too.)

> > 7. And for those that want to use lirc:  See the comms/lirc port's
> 
> Note:  LIRC users do _not_ need the remote plugin.
> 
 Yes.

> > - If vdr crashes/exits at start check permissions of files/dirs it
> >  needs write access to (below /usr/local/etc/vdr, /var/cache/vdr, /video)
> 
> If you've remapped the defaults, then those dirs, which may not be the
> ones you've mentioned, need to be writable.
> 
 True, tho if you install from ports may want to stick to the
hier(7)-compatible defaults?

> > - Small bug:  if playback of a recording doesn't start try pressing Green.
> >  (or F6 with my example remote.conf keyboard mapping.)
> 
> I've never heard of this bug.  Could you elaborate?
> 
 It mostly happens with short recordings that were already played
before...  I think.  (Tho I also yesterday saw it with vdpau on a
longer recording, for the first time.)

> > - Someone(tm) may want to write a `real' step-by-step guide how to
> >  get a FreeBSD vdr going...  (preferably someone who has never
> >  used vdr before to make sure important stuff I never think about
> >  isn't left out.)
> 
> I haven't gotten around to giving freebsd+vdr a try yet but when I do
> I'll definitely be writing a howto which I'll be more then happy to
> share.  It will however be geared towards a vdpau based system unless
> for some reason I decide to change from that, which isn't likely.
> 
 That would be nice.

> And lastly I would like to point out that a small patch is required to
> VDR's core to get North American dvb-s AC3 audio working.
> 
 Oh, if you have a link for that... :)

 Thanx!
	Juergen