From: Bob Cunningham <rcunning@acm.org>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: linux-media@vger.kernel.org
Subject: Re: HVR-950Q problem under MythTV
Date: Wed, 28 Oct 2009 21:47:16 -0700 [thread overview]
Message-ID: <4AE91E54.2030409@acm.org> (raw)
In-Reply-To: <829197380910282040t6fce747aoca318911e76aa23f@mail.gmail.com>
On 10/28/2009 08:40 PM, Devin Heitmueller wrote:
> On Wed, Oct 28, 2009 at 10:10 PM, Bob Cunningham<rcunning@acm.org> wrote:
>> I just completed a fresh install of MythTV 0.22 RC1 on my fully-updated
>> Fedora 11 system. My tuner is an HVR-950Q, connected to cable. The tuner
>> works fine under tvtime (SD) and xine (HD).
>>
>> All MythTV functions work, except LiveTV. The problem is that mythfrontend
>> times out waiting for the HVR-950Q to tune to the first station. This
>> appears to be due to the very long HVR-950Q firmware load time, since no
>> errors are reported by the backend.
>>
>> Unfortunately, mythfrontend has a hard-wired 7 second timeout for most
>> requests sent to the backend. It seems this timeout works fine under normal
>> circumstances for every other tuner MythTV works with.
>>
>> The following is repeated in dmesg after every attempt:
>>
>> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
>> usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw
>> xc5000: firmware read 12401 bytes.
>> xc5000: firmware uploading...
>> xc5000: firmware upload complete...
>>
>> It looks like the HVR-950Q driver reloads 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. Is this necessary?
>>
>> Is it possible to tell the driver to ease up on the firmware reloads? I
>> don't mind if the first attempt fails, but the second attempt should succeed
>> (without a reload).
>>
>> Alternatively, are faster firmware loads possible?
>>
>> Should I open a bug on this?
>
> Hello Bob,
>
> In order to avoid the firmware reloading condition, you need to add a
> modprobe option called "no_poweroff=1" for the xc5000 driver to your
> modprobe.conf file and then reboot your computer. I agree that this
> is a very annoying workaround, but have not had a chance to try to
> find another solution (the i2c master in the au0828 hardware is poorly
> designed and this same problem occurs in Windows but the problem is
> not as noticeable because the Windows application doesn't as
> aggressively power down the tuner).
For F11, I appended the line "options xc5000 no_poweroff=1" to /etc/modprobe.d/local.conf
Rather than power down (shudder), I did the following:
1. Unplug HVR-950Q
2. rmmod xc5000
3. modprobe xc5000 no_poweroff=1
4. Plug in HVR-950Q
> Also, in order for the video to be rendered properly, you need to make
> sure your capture resolution for LiveTV mode and the various capture
> modes is set to 720x480 (the default in MythTV is 480x480). Without
> this change, the picture will appear to be vertically stretched. This
> is actually a bug in MythTV not properly handling analog capture
> products that do not have an onboard hardware scaler (I did work in
> 0.22 to get the analog support working but have not had an opportunity
> to fix this bug yet).
Done.
> If you still have trouble, feel free to reply to this message.
>
> Cheers,
>
> Devin
All is well with the world: The tuner is tuning, MythTV is mythic, and I am a vidiot.
Thanks!
next prev parent reply other threads:[~2009-10-29 4:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 2:10 HVR-950Q problem under MythTV Bob Cunningham
2009-10-29 3:40 ` Devin Heitmueller
2009-10-29 4:47 ` Bob Cunningham [this message]
2009-10-29 4:56 ` Devin Heitmueller
2009-10-29 5:33 ` Bob Cunningham
2009-10-29 12:59 ` Devin Heitmueller
2009-10-29 13:38 ` Bob Cunningham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE91E54.2030409@acm.org \
--to=rcunning@acm.org \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox