[mythtv-users] 0.25 - livetv fails when starting on a specificchannel

[Michael T. Dean]

On 03/19/2012 06:03 PM, Ronald Frazier wrote:
> On Mon, Mar 19, 2012 at 3:48 PM, Michael T. Dean wrote:
>> Yeah, that's the better test.  That is how a user on a "modern" MythTV
>> system chooses to stream recordings from the backend--by not mounting
>> the file system locally.
>>
>> At this point the Always Stream setting is deprecated and unsupported.
>> The only reason we're still obeying it is to allow some use for
>> debugging purposes.  However, it will eventually be completely removed
>> once we get some additional code we need in place.
> OK, I did some more testing, and I found that when I unmounted NFS
> (and left AlwaysStreamFiles set to 0), the problem with this channel
> returned (just like it did when AlwaysStreamFiles was set to 1).
>
>
> I also rediscovered the reason why I originally turned on
> AlwaysStreamFiles. When watching live tv, there is tons of pixelation
> every second or two. If you pause it and let it fall about 1-2 seconds
> behind live, then the pixelation goes away. Coincidentally, when
> streaming from the backend, channel changing takes about 1-2 seconds
> longer. Furthermore, I tested using NFS without actimeo=0, and the
> result is that there is no pixelation in live tv, but channel changing
> is about 1-2 second slower than streaming from the backend (and thus
> is't 2-4 seconds slower than using NFS with actimeo=0).
>
> So now I get to take my choice of 3 sitations
>
> 1) enable AlwaysStreamFiles or unmount nfs and deal with this channel
> not working (unless someone can help me fix it)
> 2) use nfs with actimeo=0 and have horrible pixelation or be forced to
> pause for a second every time we change a channel
> 3) use nfs without actimeo=0 and deal with even slower channel changing
>
> any thoughts?

Well, if not having the file system mounted (such that the backend 
streams the recording) causes recordings from the channel to fail, we 
really need to fix that.

And, if not having actimeo=0 was preventing the ringbuffer from reading 
too close to the end of the recording, that would imply that reading the 
files locally would also read too close to the end of the file--meaning 
that needs fixing.

Both issues sound like they could be related to either a low bitrate 
channel (like Daniel mentioned), or even a misconfiguration of your 
backend (i.e. have you set any "non-standard" options to change the HD 
ring buffer size or vdpaubuffersize or ...).

Mike