some vdr intro/installation notes (watch/record/stream tv)
nox at jelal.kn-bremen.de
Sat Mar 26 23:49:52 UTC 2011
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:
> > 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.
> > - 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
> > - 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... :)
More information about the freebsd-ports