[mythtv-users] hdpvr latest firmware color saturation issue question

Steven Adeff adeffs.mythtv at gmail.com
Sun Jul 22 14:55:13 UTC 2012

On Sun, Jul 22, 2012 at 6:57 AM, Devin Heitmueller
<dheitmueller at kernellabs.com> wrote:
> On Sun, Jul 22, 2012 at 12:11 AM, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
>> gotcha!
>> yea, it would be good if Myth could run the fix so the user doesn't
>> have to. apparently there's a fix for the linux driver but some hiccup
>> in the patch approval system is causing it to not go through.
> The driver fix was approved and went upstream in kernel 3.4.  If
> you're running that version and still have the problem, then that
> should definitely be discussed.

ah! ok, as far as I could find it hadn't been, and I'm only running
3.2. So, 3.4 does not require running the v4l2-ctl command to fix the
color issue?
if so, the hdpvr entry in the wiki should be updated to reflect this.
and I should look at upgrading to 3.4 (to hopefully avoid any possible
future headaches on this issue)

here's what I wrote in the other thread, as to my "solution" and how I
got there:

so since I sent that email we've been playing around more. oddly we
have yet to have a mis-tune, which is nice.

I previously had a sleep command in my script, but it did not seem to
do anything so I removed it, and nothing seemed to change.

I'm trying to figure out how the v4l2-ctl command to fix the
saturation issue plays into the channel change script. The reason is,
if I put it in the channel change script it does not affect the
initial entry into LiveTV but does after a channel change.

so I tried as you said and put a 15 second sleep, and yes, it does
delay the tuning!
so there is the delay, but no matter how long I set it for the colors
always come up bad when first going to livetv, but, oddly, when
changing channels the colors are fine.

so then I created a second script, just to change the pvr settings,
that the channel change script runs in the background (using &) with a
4 second sleep in that script. this causes the initial entry into
livetv to fix shortly after video starts to play, but also for channel
changes to start wrong and then fix shortly after!
if however in this second script I run the channel change command and
then sleep and then run the command again, it fixes the initial livetv
entry AND on channel changes there is no perceptible lag in the fix
(ie it comes up correct).

so that seems to have solved it, though I'm baffled as to whether I'm
the only one with this "delay" issue, or I just missed this in the
wiki entry and mailing lists and had to re-invent the wheel so to

Before you ask, read the FAQ!
then search the Wiki, and this list,
Mailinglist etiquette - http://www.mythtv.org/wiki/Mailing_List_etiquette

More information about the mythtv-users mailing list