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

Michael T. Dean mtdean at thirdcontact.com
Mon Mar 19 19:08:25 UTC 2012


On 03/19/2012 02:40 PM, Ronald Frazier wrote:
> On Mon, Mar 19, 2012 at 2:20 PM, Michael T. Dean wrote:
>> Almost definitely NFS misconfiguration, as Daniel mentioned.
>> http://www.mythtv.org/docs/mythtv-HOWTO-23.html#ss23.8 (specifically the
>> actimeo option).
> Except as I mentioned, I only have the issue when the Always Stream
> setting is turned on. Thus it shouldn't even be trying to use NFS,
> right? I didn't notice anything in the logs to indicate it was trying
> NFS. Turning off Always Stream resulted in it using NFS, and that
> worked fine.

Right.  If you force it to do something other than default behavior, it 
does what you say, not what it should.

> But for the record, I didn't have actimeo=0 set. I don't think that
> would have made a difference based on my understanding, but just to be
> sure I'll try turning the Always Stream on

It should be off.  Off = "do the right thing."  On = "I don't care what 
you think, I know better."  :)

The "default" now is off.

>   tonight and see if
> actimeo=0 makes any difference (yes, I'll be sure to unmount/remount
> and check nfsstat to make sure the change took effect).

The only reason you still have that setting enabled is because you 
enabled it in a 0.23-fixes or below version of MythTV.  When we removed 
the setting, we didn't change existing systems because we figured that 
if the user was using it as a workaround for a broken configuration, 
it's easier to let them keep using it on existing systems and then just 
fix new systems as they bring them up.

However, I will say that no one should /ever/ have to set that setting, 
so please don't go poking around in the database and add the setting on 
new systems.  Instead, please configure them properly so you don't need it.

Those who want to remove old values can do so with:

mysql -umythtv -p mythconverg -e 'DELETE FROM settings WHERE value = 
"AlwaysStreamFiles";'

>> If you think there's a reason, then there's some other problem with your
>> configuration that you're not fixing that make you think so.  And, when
>> fixed, your system will work properly without having to force a value
>> for the setting.
> Probably true. I can't recall exactly why I turned on always stream,
> but it was due to some playback issue. I think it might have been
> frequent pausing when watching an in-progress recording (ie: watching
> slightly behind "live").

Yeah.  There was a point when we all thought that setting was 
useful/important.  Unfortunately, we hadn't realized that when Storage 
Groups were added to MythTV, the setting became nothing more than a 
workaround for misconfigurations, so it stayed in place for a couple of 
versions where it shouldn't have been.

And, as I mentioned, we left the setting enabled on systems where it was 
enabled with the hope that it would disappear over time through attrition.

>   And yeah, I can definitely see how that
> probably may have been due to not having actimeo=0
>
> When I just disabled always stream yesterday, playback started working
> but I was having a lot of macro-blocking in the video, even in
> completed recordings. My nfs mount strings in fstab are the same as
> they've probably been for 5 years now, so I went and changed them.
> That fixed the macro-blocking issue. I was assuming the key was the
> read/write block size...I previous had it at 32k, and upgraded it to
> 256k.

Right.  In current NFS, you should not even specify rsize and wsize.  
Not forcing those values lets the kernel's NFS drivers choose the 
most-appropriate value based on the client and server systems.  (I.e. 
another "just do the right thing.")

>   I see in the link you posted it says to just leave that out.
> Probably a good idea.

Yep.

> Thanks for that link. It's probably a good thing to review these
> things from time to time. For instance, much like my mount string,
> I've also been copying over my samba config file for several years
> now. I saw a thread in this forum a while back about slow samba
> transfer speed. When I applied the suggestion in that thread to my
> config, my linux-to-windows transfer speed went from 25MB/s to 85MB/s.
> Times change, and so should your config :)

Wow.  I'll have to find that thread (though I don't use Samba/CIFS, a 
friend does, and I know he has issues with the speed).

But I completely agree--it's good to recheck your configuration 
occasionally, especially after upgrades.  The challenge is checking 
everything (as there's so much configuration involved in any system).

Mike


More information about the mythtv-users mailing list