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

[Juergen Lock]

On Sat, Mar 26, 2011 at 07:05:01PM -0700, VDR User wrote:
> On Sat, Mar 26, 2011 at 4:44 PM, Juergen Lock <nox at jelal.kn-bremen.de> wrote:
> >> 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?)
> 
> I'm not a fan of scripts like runvdr to be honest.  I opted to just
> write my own from scratch.  I use the bash shell and hadn't considered
> whether or not freebsd has it available as well.  I hope so!
> 
Yes bash is in ports.

> >> 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... :)
> 
> Originally vdpau support was being developed against the 1.1 branch
> but it eventually matured to the point where it was merged into
> xine-lib-1.2 directly.  Since then all development has been against
> xine-lib.1.2 with no backporting that I'm aware of.  When vdpau was
> merged, I made the switch to the 1.2 branch.  There have been a few
> bumps in the road but those were all resolved and my experience now is
> that xine-lib-1.2 vdpau is very stable.  I'd say it's worth trying and
> see if you get the same results because it's sure a lot easier then
> maintaining a bunch of patches. :)
> 
 Well it would also have to work for all the other ports that use
libxine too, vdr is just one of them...  And if it were really
stable wouldn't they do a release? :)  (Although I guess one could
do a libxine-devel port like there is ffmpeg-devel that is a snapshot
too...)

> >> 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?
> 
> It could be.  I know vdpau support was completely re-written from
> scratch a little while back.  There's also another alternative vdpau
> implementation being developed (also against 1.2) which is already
> working but looking good so far.  IIRC it needs some work and a lot of
> code clean-up though.
> 
> >> > - 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.)
> 
> I tried it here and couldn't reproduce the problem.  I wonder if this
> is related to using xine-lib-1.1 vdpau?  Are you aware of any linux
> users with the problem also?
> 
 I'll have to ask around, but I already saw the bug before I used
vdpau, and it was with sd recordings too.

> >  Oh, if you have a link for that... :)
> 
> I actually don't but I'll attach it to this post. :)

 Thanx.  I wonder if that is more a `hack' than a proper fix tho
I didn't try to find the relevant specs...

 Cheers,
	Juergen