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

[VDR User]

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.

>  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.

> 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.

> 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.

> 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 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.

>        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.

>   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

> 7. And for those that want to use lirc:  See the comms/lirc port's

Note:  LIRC users do _not_ need the remote plugin.

> - 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.

> - 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?

> - 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.

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.