Opened 15 years ago

Closed 14 years ago

Last modified 13 years ago

#7198 closed defect (invalid)

DVB tuning fails with HVR-1300 on Linux kernels starting with 2.6.27

Reported by: linux@… Owned by: Janne Grunau
Priority: minor Milestone: unknown
Component: MythTV - DVB Version: head
Severity: medium Keywords: hvr-1300 tuning
Cc: linux@… Ticket locked: no

Description

Hi,

after upgrading my Linux kernel on my Debian box running mythTV from 2.6.26 to 2.6.30 DVB tuning would fail with 'could not get signal lock', no matter which channel I tried. I tried different kernels and it seems the problem starts with 2.6.27 and get worse with 2.6.28 and the following.

I tried tuning with kaffeine and it does not find all but most of the channels. tzap can lock all channels.

I have attached the output of the current head revision in trunk for mythtv-setup given a single input channel on both 2.6.26 and 2.6.31-rc7 as well as the tzap output on 2.6.31-rc7 to illustrate the problem.

Please let me know if you need further info.

Thanks and best wishes,

Martin.

Attachments (7)

mythtv-setup-2.6.31-rc7-edited.log (29.0 KB) - added by linux@… 15 years ago.
channel tuning output on Linux kernel 2.6.31
mythtv-setup-2.6.26-edited.log (10.3 KB) - added by linux@… 15 years ago.
channel tuning output on Linux kernel 2.6.26
mythtv-setup-2.6.26-edited.2.log (10.3 KB) - added by linux@… 15 years ago.
channel tuning output on Linux kernel 2.6.26
tzap-2.6.31-rc7.log (746 bytes) - added by linux@… 15 years ago.
tzap output for same channel on 2.6.31
femon-mythtv (2.4 KB) - added by anonymous 14 years ago.
femon output from MythTV scanning of one multiplex
channelscan-scan-7198.txt (2.9 KB) - added by anonymous 14 years ago.
channels file made with scan, used as input to tzap tuning
tzap-7198 (748 bytes) - added by anonymous 14 years ago.
Output from tzap

Download all attachments as: .zip

Change History (15)

Changed 15 years ago by linux@…

channel tuning output on Linux kernel 2.6.31

Changed 15 years ago by linux@…

channel tuning output on Linux kernel 2.6.26

Changed 15 years ago by linux@…

channel tuning output on Linux kernel 2.6.26

Changed 15 years ago by linux@…

Attachment: tzap-2.6.31-rc7.log added

tzap output for same channel on 2.6.31

comment:1 Changed 14 years ago by Janne Grunau

Status: newinfoneeded_new

strange, I would say a kernel bug. Please check the frontend status during the scan with femon. if it's is never FE_HAS_LOCK, please attach tzap's channels.conf. I suspect a difference in the parameters. You could also check scanning with more parameters set to auto.

Changed 14 years ago by anonymous

Attachment: femon-mythtv added

femon output from MythTV scanning of one multiplex

Changed 14 years ago by anonymous

Attachment: channelscan-scan-7198.txt added

channels file made with scan, used as input to tzap tuning

Changed 14 years ago by anonymous

Attachment: tzap-7198 added

Output from tzap

comment:2 Changed 14 years ago by anonymous

I have a HVR-4000, but the DVB-T part seems to be equal: From mythtv-setup-2.6.31-rc7-edited.log: 2009-09-28 20:58:07.024 DVBChan(4:/dev/dvb/adapter0/frontend0): Using DVB card /dev/dvb/adapter0/frontend0, with frontend 'Conexant CX22702 DVB-T'. From my scan: 2009-10-08 00:37:05.451 DVBChan(1:/dev/dvb/adapter0/frontend1): Using DVB card /dev/dvb/adapter0/frontend1, with frontend 'Conexant CX22702 DVB-T'. So I hope these logs are relevant.

comment:3 in reply to:  1 ; Changed 14 years ago by linux@…

Replying to janne:

strange, I would say a kernel bug. Please check the frontend status during the scan with femon. if it's is never FE_HAS_LOCK,

A funny thing happened:

  • when I start femon and then start the channel scan I get a lock and all channels are found
  • However, when I run the channel scan without having femon running at the same time no channel gets found
  • If a channel is being scanned and I start femon then, still nothing is found.

Could it be that femon does some initialization on the adapter that is missing in otherwise?

please attach tzap's channels.conf. I suspect a difference in the parameters. You could also check scanning with more parameters set to auto.

I have actually been using the same channels.conf for both mythtv-setup and tzap during my testing so there is no difference.

Thanks for your help and best wishes,

Martin.

comment:4 in reply to:  3 ; Changed 14 years ago by Janne Grunau

Status: infoneeded_newnew

Replying to linux@martin-kittel.de:

  • when I start femon and then start the channel scan I get a lock and all channels are found
  • However, when I run the channel scan without having femon running at the same time no channel gets found
  • If a channel is being scanned and I start femon then, still nothing is found.

strange

Could it be that femon does some initialization on the adapter that is missing in otherwise?

I don't think so, but I'll look what femon does exactly.

I have actually been using the same channels.conf for both mythtv-setup and tzap during my testing so there is no difference.

could you test the full scan germany?

There is a bug in the kernel for the HVR-1300/4000 which seems to be related

https://bugs.launchpad.net/mythtv/+bug/439163

it should only affect 2.6.29+ though

comment:5 in reply to:  4 Changed 14 years ago by anonymous

Replying to janne:

could you test the full scan germany?

I tried with 2.6.31 vanilla and again had the same problem: if femon was started before mythtv-setup, the scan was ok, if started femon at a later time, no channels were found.

There is a bug in the kernel for the HVR-1300/4000 which seems to be related

https://bugs.launchpad.net/mythtv/+bug/439163

I have tried the patch/revert to cx88-dvb.c mentioned in that thread and that seems to do the trick for me as well. I can watch TV again. For now it seems that tuning takes a bit longer than before because I get the channel lock warning which I did not see with earlier kernels. After a few seconds, however, the picture appears. I will keep an eye on this.

BTW, http://svn.mythtv.org/trac/ticket/7292 seems to be about the same issue.

it should only affect 2.6.29+ though

Judging from the time the change was made it could have been 2.6.27 as well, but I am no git expert and cannot determine when it actually went into mainline.

What is the correct way to proceed now? Wait for a kernel patch?

In any case, thanks for your help!

comment:6 Changed 14 years ago by linux@…

Hi,

I just checked: the problem is fixed in 2.6.32, so this bug can be closed.

Best wishes,

Martin.

comment:7 Changed 14 years ago by stuartm

Resolution: invalid
Status: newclosed

comment:8 Changed 13 years ago by fgunni@…

The real bug seems to be found. The other 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 (Did help on the other ticket:) ) This time i need to add some more text it seems.

Note: See TracTickets for help on using tickets.