Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#7292 closed defect (invalid)

DVB-T channel scan timeout on HVR-1300

Reported by: Marc Randolph <mrand@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - Channel Scanner Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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

Attachments (2)

mythtv-setup-singlefreq.log (36.3 KB) - added by Marc Randolph <mrand@…> 14 years ago.
mythtv-setup.log.gz (27.5 KB) - added by Marc Randolph <mrand@…> 14 years ago.

Download all attachments as: .zip

Change History (12)

Changed 14 years ago by Marc Randolph <mrand@…>

Attachment: mythtv-setup-singlefreq.log added

Changed 14 years ago by Marc Randolph <mrand@…>

Attachment: mythtv-setup.log.gz added

comment:1 Changed 14 years ago by 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

comment:2 Changed 14 years ago by 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

comment:3 Changed 14 years ago by 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

comment:4 Changed 14 years ago by 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.

comment:5 Changed 14 years ago by fgunni@…

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

comment:6 Changed 14 years ago by danielk

Resolution: invalid
Status: newclosed

Thanks Frank!

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

BTW Does [22406] help at all?

comment:7 Changed 14 years ago by 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

comment:8 Changed 14 years ago by 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.

comment:9 Changed 14 years ago by 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

comment:10 Changed 13 years ago by 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 :)

Note: See TracTickets for help on using tickets.