DVB-T channel scan timeout on HVR-1300

[Marc Randolph <mrand@…>]

Updated to [22350], and hardware worked previously for this user (0.21)

mythtv-setup --verbose channelscan,siparser,channel,record,extra

Two files attached, one single frequency, and one for bunches.

Settings are:
Signal timeout: 10000 msec
Tuning timeout: 10000 msec
DVB tuning delay: 100 msec

[Marc Randolph <mrand@…>]

It is believed that this is likely due to a change in the kernel (it has not worked reliably in several versions, so it doesn't appear to be a regression that just appeared). kaffeine, tzap, mplayer reportedly work

[hogliux]

I have the same error on my computer and i'm trying to further nail down the problem. I've noticed that with upgrading the kernel to more recent kernel versions kaffeine also doesn't lock to all available stations ( only to some ). tzap in the dvb-utils package can lock on all available channels. So i compared the tuning code of caffeine and tzap and modified both codes to give me a hexdump of the FE_SET_FRONTEND ioctl structure. Both were exactly the same. That means kaffeine and tzap send the exact same parameters to tune the drivers, but for some reason kaffeine fails to get a lock.

The next difference i noticed is that when kaffeine or mythtv tunes and sleeps waiting for a lock the system load goes up on some kernel threads. This doesn't happen with tzap. So this is my guess (haven't checked it yet, but will do so this week): the Hauppage 1300 has a built-in mpeg decoder and i think tzap sets up the driver in such a way ( with the DMX_SET_PES_FILTER ioctl and the DMX_OUT_TS_TAP parameter ) that the mpeg tes data is not decoded but sent to dvr0, while tuning. kaffeine sets this flag AFTER tuning and i guess the card is then in decode mode by default meaning, that the card will try to decode the mpeg-ts data in hardware. Maybe, if this, for some reason fails ( maybe because of bad mpeg decoder firmware or weak signal ) then the driver won't lock the signal ( which would actually be a driver bug, because the signal lock should have nothing to do with the hardware mpeg decoder ). I really haven't checked this yet but will do so if i have time this week.

Did someone else observe the system load go up while tuning?

Thanks for your replies Mark!

hogliux

[Frank Sagurna <fgunni@…>]

I just searched some additional info. I post it here without knowing if one is helpful, but if it is, all info is in place with this bug:

linux-media ML: ​http://www.mail-archive.com/linux-media@vger.kernel.org/msg08897.html mythtv ML: ​http://www.gossamer-threads.com/lists/mythtv/users/401762 ​http://www.pubbs.net/kernel/200908/24527/ (- cx88: HVR1300 ensure switching from Encoder to DVB-T and back is reliable;) <- maybe this one was contraproductive

[Frank Sagurna <fgunni@…>]

I seem to got it working again. Dont know exactly (i am at work and did everything remote, so i cant check in frontend etc.) But i remcompiled the cx88 module with reverting two patches (randomly not knowing what i am doing, but from naming could be the ones) And now in mythweb i can see the first recording with growing file size. Seems prmoising. I reverted these two patches by hand (Only the HVR1300 parts):

• cx88: HVR1300 ensure switching from Encoder to DVB-T and back is reliable;

​http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04710.html (After this one i did not see success, but as stated, from remote and as amateur)

• [linuxtv-commits] [hg:v4l-dvb] cx88: advise/acquire clean-up for HVR-1300/3000/4000

​http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg02195.html (After this one i finally saw getting EIT data, and recording seems to work.)

I will recheck when at home.

[fgunni@…]

So i digged it down to a driver issue. See ​https://bugs.launchpad.net/mythtv/+bug/439163/comments/36 for a solution

[danielk]

Thanks Frank!

Closing as invalid, as the error is upstream in the Linux kernel.

BTW Does [22406] help at all?

[anonymous]

Hi,

just for the record. If people search for this problem on google: reverting the patch mentioned in [22406] also solved the problem on my computer. I will try to get the maintainers of cx88 to make the appropiate changes up stream in the kernel sources.

thanx

[Frank Sagurna <fgunni@…>]

anonymous: Which patch do you mean? The Changeset 22406 did not help for me. Only reverting the patch i mentioned did help.

[Gunni]

Just one last additional comment as the patches seem now quite good. Here is the solution for ubuntu users:

​https://bugs.launchpad.net/mythtv/+bug/439163/comments/61

[fgunni@…]

The real bug seems to be found. My solution is now obsolete: Hope this gets into kernel quick.

​http://www.kernellabs.com/blog/?p=1568

How can i prevent that post to fall in the spam filter .... maybe by this line :)