[mythtv-users] Live TV playback frustration

[Adrian Saul]

> Oh - my humble experience are really in favour of 0.26.
> Lets put aside for moment OP context (which for me seems to be rather 
> particular installation/config issue): 0.26 has many fundamental 
> changes i.e. within thread locking/synchronization infrastructure 
> which I clearly see as huge improvement. I feel them in daily use. 
> Believe me !
> Currently I would say 0.26 is first release I would qualify as: it 
> works as it should (regarding PVR/LiveTV functions).

Well - upgraded to 0.26 by throwing out my old install and installing a 
fresh 12.04 Mythbuntu image and switching it up to 0.26.  Config is 
mostly the same although I switched some NFS mounts to version 3 instead 
of NFSv4 due to some permission issues I encountered - seems a little 
happier with NFSv3 but hard to gauge really.   A positive was generally 
most of my hardware is now supported out of the box with 12.04 (no 
stuffing with bleeding edge versions of linux media git compiles or 
LIRC).  Most of the work was in restoring small config files and 
dropping in a firmware or two.

As for 0.26 I am yet to see any obvious change that has jumped out at 
me, but gut feel is that things are a little smoother and more 
consistent.  Only nasty part of upgrade was a need to manually add some 
timezone data to the database and a few SQL errors during schema upgrade 
(nothing it failed on, just took a long time to process).  I did pick up 
on some recording rules no longer working (present, but not picking 
things they should have) but not sure if that is related to a channel 
rescan I ran as well.

Got some time to test a few known issues that I was griping about:

1. Playing an "in progress" recording on one frontend and then playing 
something else on the other does not cause the in progress one to crash 
- seems now to be fixed (fingers crossed).
2.  "Watch TV" and changing channels on the standalone frontend still 
causes it to exit with a buffering issue, but that could be my NFS setup 
(actime?)
3. Fast forwarding in an "in progress" recording and getting near the 
end - still causes it to error out (as does attempting to jump to early).

A side issue that is still bugging me.  On the main frontend I get a 
blank screen with "Please Wait" while it buffers up after you pick a 
recording to watch.  On the other frontend I get a really long pause to 
start playback and no feedback that the button was pressed i.e no blank 
screen or "please wait", just sitting in the selection screen not doing 
anything.   Odd as both are set to VDPAU with both Nvidia GPUs (Ion330 
and 8400GS) and I can't find any frontend config options that would 
affect the behaviour.  Any ideas where this would be coming from?  At 
least getting the feedback of "Please wait" would be good as at the 
moment we don't even know if the remote worked or not.

There is some lag on the playback startup and that occasionally affects 
the other frontend too - so far the only thing in the logs is time 
taking to do "SyncPositionMap" - which is odd because following the code 
and doing SQL behind the query completes instantly when I test it but in 
the logs I can see multiple instances where it takes 13 seconds or 
more.   Might take a closer look at what the database is doing because 
the code shows nothing else that would block this.

Cheers,
   Adrian