Hi Patrick,
No wonder I was confused. :)
I haven't had a chance to test yet and it mostly looks good. However
you've got a copy&paste bug in the module param description for
both the dib3000mc and the dib7000p. See below ... the param
description should be for "buggy_sfn_workaround" not "debug".
+static int buggy_sfn_workaround;
+module_param(buggy_sfn_workaround, int, 0644);
+MODULE_PARM_DESC(debug, "Enable work-around for buggy SFNs (default:
0)");
+
Thanks again, will let you know if it's good once I've done some
testing.
Thanks,
Matt
Patrick Boettcher wrote:
I'm stupid. I arrived at my desk this morning and the commit window was
still open.
It is now committed.
Patrick.
On Tue, 31 Jul 2007, Matt Doran wrote:
Hi Patrick,
Thanks for that Patrick. My patch fixed the problem for me and someone else I
know with the same card. I'll try the fix tonight, and also will get the
other guy to test it.
What module parameter do I need to use? Do I also need the new firmware?
I looked through your repository and couldn't see the change that fixed the
problem, what was the revision? ... e.g. my patch added a module parameter to
dib3000mc, but I can see a new module parameter there.
Thanks,
Matt
Patrick Boettcher wrote:
Hi Matt,
Based on your Idea I just committed something which will fix your problems
using a module parameter.
I don't know why Hauppauge has splitted the fix into two, it is not useful,
both register-changes are required to solve the issue.
By using those settings one will decrease the mobile performance of the
receiver, but for fixed-reception it is OK.
Can you please try it from my hg repo: http://linuxtv.org/hg/~pb/v4l-dvb/?
regards,
Patrick.
On Thu, 19 Jul 2007, Matt Doran wrote:
Hi Patrick,
I tracked down the code that sets up the registers in dib3000mc.c. I
created
a patch to add a "fix_sfn" module option to the dib3000mc modele. e.g.
when
fix_sfn 0x01 bit is set, configure register 29 -> 0x1073 ... when fix_sfn
0x02
bit is set, configure register 108 -> 0x4000. I've tested this with
"fix_sfn" set to 3 to enable both fixes, and it doesn't
cause any regressions. Tonight I have not had any reception/stuttering
problems (it doesn't happen all the time), so I'm not sure if it fixes the
problem..... but I'll continue to use this to see if it successfully
resolves
my issues. I'll also ask others I know who see this problem to test this
fix.
Can you review this patch? Does it look right?
I wasn't sure what to call the module option, or how to describe the
options
... if you have any suggestions I'd be happy to adjust the patch.
Regards,
Matt
Patrick Boettcher wrote:
Hi,
I nothing really important happens I'm trying to provide something this
or
beginning of next week.
Patrick.
On Sun, 15 Jul 2007, Matt Doran wrote:
Hi there,
The Nova-T 500 has some serious problems with some channels in various
locations around Australia. These channels show serious video
break-up/stuttering like there is poor reception, however this is not
the
case. Using other tuners (e.g. other cards, or tuners in TVs), or
using
the Nova-T 500 on Windows doesn't exhibit these problems. I raised
this
issue 3 or four months ago
(http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017065.html).
Patrick Boettcher indicated that it relates to some peculiarities with
the
DVB broadcast
(http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017102.html).
The Hauppauge windows drivers now have a registry key
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HCW99BDA\Parameters\FixSFN)
that can be used to modify the tuner's behaviour to fix this problem.
I'd like to work on a patch for the drivers to add a module option
"fix_sfn", that does the same as the windows drivers. But need to
know
what registry settings need to be changed. If Patrick or someone from
Hauupauge or Dibcom could give me this information, I'd like to
develop
the initial patch.
Thanks in advance,
Matt
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
|
