[mythtv-users] mythfrontend timeout when tuning HVR-950Q

[Devin Heitmueller]

On Wed, Oct 28, 2009 at 9:49 PM, Bob Cunningham <FlyMyPG at gmail.com> wrote:
> On 10/28/2009 04:03 PM, Bob Cunningham wrote:
>>
>> I just finished a fresh install of 0.22 RC1 from
>> rpmfusion-updates-testing on Fedora 11.
>>
>> Everything went well from the start:
>> - Configuration OK (including XMLTV load for QAM SD, and channel scan
>> for QAM HD)
>> - mythfilldatabase OK
>> - MythMusic OK
>> - MythWeb OK (still need to clean up channel mapping and tweak other
>> settings)
>>
>> But I can't watch LiveTV! My HVR-950Q works fine with tvtime (SD) and
>> xine (HD).
>>
>> Neither the frontend nor the backend are crashing. Google searches yield
>> no help.
>>
>> The output from mythfrontend is:
>>
>> 2009-10-27 16:40:12.573 TV: Attempting to change from None to Watching
>> WatchingLiveTV
>> 2009-10-27 16:40:12.578 MythContext: Connecting to backend server:
>> 127.0.0.1:6543 (try 1 of 1)
>> 2009-10-27 16:40:12.579 Using protocol version 50
>> 2009-10-27 16:40:12.582 Spawning LiveTV Recorder -- begin
>> 2009-10-27 16:40:19.586 MythSocket(887ddd8:40): readStringList: Error,
>> timed out after 7000 ms.
>> 2009-10-27 16:40:19.587 RemoteEncoder::SendReceiveStringList(): No
>> response.
>> 2009-10-27 16:40:19.587 Spawning LiveTV Recorder -- end
>> 2009-10-27 16:40:19.587 GetEntryAt(-1) failed.
>> 2009-10-27 16:40:19.589 EntryToProgram(0 at Wed Dec 31 16:00:00 1969)
>> failed to get pginfo
>> 2009-10-27 16:40:19.589 TV Error: HandleStateChange(): LiveTV not
>> successfully started
>> 2009-10-27 16:40:19.589 We have a RingBuffer
>> 2009-10-27 16:40:19.639 TV Error: LiveTV not successfully started
>>
>> /var/log/mythtv/mythbackend.log contains no errors or warnings.
>>
>> Since I'm using an HVR-950Q, and since the HD channel scan worked fine,
>> my guess is the problem may be the slow firmware load, which takes about
>> 8 seconds, but it seems mythfrontend times out in 7 seconds.
>>
>> The driver seems to reload the firmware at every possible opportunity,
>> independent of the hardware state, each time either the SD or HD device
>> is opened, such as when changing from an SD channel on /dev/video0 to an
>> HD channel on /dev/dvb/adapter0. So this delay will happen a lot.
>>
>> Any way to have the frontend be a bit more patient?
>
> This is due to the value of kShortTimeout being hard-coded to 7000 in
> mythsocket.cpp.
>
> Can this be changed to a configurable setting?  Perhaps the tuner
> configuration in mythsetup should have a checkbox for "Slow Tuner" that the
> frontend could read for LiveTV, that would cause the timeout to double.
>
> If it has to stay as a constant, it should be set higher.
>
> Should I open a bug on this?
>
>> Or can I tell the driver to ease up on the firmware reloads?
>
> If nobody here has any suggestions, I'll ask on the linux-media list.

Hi Bob,

Sorry I've been tied up in development and not watching email for the
last couple of hours.  I answered your email over on linux-media
before I got around to looking at my mythtv-users folder.

I *am* glad to see thought that you actually tracked down where the
timeout is coming from.  I hadn't yet had a chance to chase down where
in the MythTV source the timeout was actually occurring.  It would be
great to see this made configurable, since it's easier for users to
reconfigure a MythTV setting than a modprobe option.  Alternatively, I
might want to float past the MythTV devs the idea of making the
timeout 10 seconds instead of 7, which would result in the 950q
working without the user needing to do anything (and in reality,
people shouldn't be hitting the timeout anyway, so there shouldn't be
a huge complaint about the difference between ten seconds and seven).

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller