Thanks Andy, and apologies for forgetting conventions.

OK, I got it to work but only after installing 2.6.32-r2 (I was on
2.6.31-r6) so this may have been the problem. Followed your instructions
exactly as before with the new kernel and everything worked first time.
I have run 40 test recordings (1 min long!) and none of them had audio
problems. My first proper recording has also just completed with no
problems. So far, no signs of any other instability issues either.

Incidentally, I then had problems not being able to send commands to my
IR blaster, but that may have had nothing to do with ivtv and just
something in the new kernel. Fixed the problem by compiling the serial
driver as a module, as recommended by LIRC. Strange that it always
worked OK before.

Now I must remember to recompile nvidia...


Andy Walls wrote:
> On Wed, 2010-01-20 at 11:53 +0000, Robert Sharp wrote:
>   
>> Andy,
>>
>> Thanks for the help. I have followed your instructions but I cannot load
>> the ivtv module. It fails, complaining about:
>>
>> [252187.201342] ivtv: Unknown symbol ir_codes_hauppauge_new_table
>> [252187.204061] ivtv: Unknown symbol ir_codes_rc5_tv_table
>> [252187.205281] ivtv: Unknown symbol ir_codes_avermedia_cardbus_table
>>
>> Any ideas? I have double-checked the installed modules and there are
>> none relating to ivtv. Can't see why this should be a problem when the
>> vanilla ivtv driver
>> installs fine.
>>
>> Best regards
>> Robert
>>     
>
> Hi Robert,
>
> First, you may find posting to the list more expedient: others may be
> able to help you; and others may benefit from the answer.  (For example,
> in this particular case I think Devin already knows the answer and could
> have helped you sooner if your mail went to the list.)
>
>
> The latest ivtv module now knows about some bundled remotes with various
> cards.   For those remotes to "work out of the box", the ivtv driver
> needs the remote keypress mapping tables.  Those tables are included in
> the new version of the ir-common module you should have built and
> installed along with the ivtv module. (Maybe I need to fix a Kconfig
> file dependency...)
>
> $ find v4l-dvb/linux/ -name "ir*c"
> v4l-dvb/linux/drivers/media/IR/ir-keytable.c
> v4l-dvb/linux/drivers/media/IR/ir-functions.c
> v4l-dvb/linux/drivers/media/IR/ir-sysfs.c
> v4l-dvb/linux/drivers/media/IR/ir-keymaps.c
> v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c
>
>
> Note, that Mauro recently shuffled the position of these files in the
> source tree to the IR directorty.  That means where the ir-*.ko kernel
> modules get installed has also moved:
>
> $ find /lib/modules/`uname -r`/ -name "ir*ko"
> /lib/modules/2.6.27.30-170.2.82.fc10.x86_64/kernel/drivers/media/video/ir-kbd-i2c.ko
> /lib/modules/2.6.27.30-170.2.82.fc10.x86_64/kernel/drivers/media/IR/ir-common.ko
> /lib/modules/2.6.27.30-170.2.82.fc10.x86_64/kernel/drivers/media/IR/ir-core.ko
> ....
>
>
> So:
>
> 1. Did "make" appear to make all the new v4l-dvb modules, including the
> ivtv and ir-* modules?  Did "make install" appear to install them all?
>
> 2. Do you have duplicate ir-common.ko and ir-core.ko modules
> under /lib/modules/`uname -r` ?  If so move, backup or delete the
> duplicates that are not in the IR directory.  Are ir-*ko objects in the
> IR directory?  Did "make install" appear to perform a depmod -a?
>
>
> If building the latest source modules is too much to deal with, then
> please don't knock yourself out.  Waiting is always an option; although
> maybe not a staisfying one at times.  (I don't expect ordinary users and
> subscribers to the ivtv-users list to think they need to put herculean
> efforts into trying to test bleeding edge code.)  The fix will get into
> the main v4l-dvb repository soon.  Propagation to 2.6.33 may take some
> time.  Propagation of 2.6.33 to distributions will take more time.
> However, the change will eventually make it to the end user that way.
>
> Thanks again.
>
> Regards,
> Andy
>
>
>   
>> Andy Walls wrote:
>>     
>>> On Sun, 2010-01-17 at 09:05 +0000, Robert Sharp wrote:
>>>   
>>>       
>>>> I recently upgraded a PC with the PVR-150 to 2.6.31 and am suffering
>>>> from the return of the tinniness problem. There is an interesting
>>>> discussion in the dev list but no clear resolution. Can someone explain
>>>> either when the fix discussed will be available to ordinary users or how
>>>> we can apply the patch to fix this.
>>>>     
>>>>         
>>> Robert,
>>>
>>> I have a fix that Martin is (rightly) not happy with here:
>>>
>>>     http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/
>>>
>>> if you could test it out and let me know if it make the problem go away,
>>> that would be great.
>>>
>>> Then as a second step, if you can normally reliably reproduce the tinny
>>> audio, look to reduce the delays in this part of the patch:
>>>
>>>     http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/rev/7753cdcebd28#l2.11
>>>
>>> I would appreciate it.  I was thinking 10 msec for the first msleep()
>>> and 140 to 100 msec for the second msleep.
>>>
>>> The easiest way to test it is:
>>>
>>> 1. Download:
>>>     http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/archive/tip.tar.gz
>>>
>>> 2. untar
>>> 3. Change into the directory and build:
>>>
>>>     cd v4l-dvb-bugfix-blahblah/
>>>     make
>>>
>>> 4. Back up your current modules in /linux/`uname -r`/kernel/media
>>> if you want to roll back.
>>>
>>> 5. Then install the modules as root,unload any running modules, and load
>>> the new ivtv module:
>>>
>>>     cd v4l-dvb-bugfix-blahblah/
>>>     make install
>>>     (kill the mythbackend or anything else that has the devices open)
>>>     make unload
>>>     make unload
>>>     modprobe ivtv
>>>
>>> And you're ready to test.
>>>
>>>
>>> Thanks,
>>> Andy
>>>       
>
>
>   

_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Reply via email to