[mythtv-users] known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24)
Igor Cicimov
icicimov at gmail.com
Thu Jun 7 09:54:59 UTC 2012
On Thu, Jun 7, 2012 at 4:20 PM, Nick Rout <nick.rout at gmail.com> wrote:
> On Thu, Jun 7, 2012 at 1:23 PM, Igor Cicimov <icicimov at gmail.com> wrote:
> > On Thu, Jun 7, 2012 at 11:16 AM, Igor Cicimov <icicimov at gmail.com>
> wrote:
> >>
> >> On Thu, Jun 7, 2012 at 10:59 AM, Igor Cicimov <icicimov at gmail.com>
> wrote:
> >>>
> >>> On Thu, Jun 7, 2012 at 9:39 AM, Igor Cicimov <icicimov at gmail.com>
> wrote:
> >>>>
> >>>> On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre
> >>>> <vincent.mcintyre at gmail.com> wrote:
> >>>>>
> >>>>> curiosity got the better of me...
> >>>>>
> >>>>>
> >>>>>
> http://git.linuxtv.org/media_tree.git/commitdiff/f0ef7c88ca919912011593d2392a59c2fde04748?hp=4911085fa3342d2ccb04f84c2987305b86785ebf
> >>>>>
> >>>>> Perhaps this module needs checking for issues like the one in
> >>>>> tuners-xc2028.c?
> >>>>>
> >>>>> Might be worth trying to load the driver module with the debug
> >>>>> parameter turned on
> >>>>> and doing a scan?
> >>>>> _______________________________________________
> >>>>> mythtv-users mailing list
> >>>>> mythtv-users at mythtv.org
> >>>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
> >>>>
> >>>>
> >>>>
> >>>> Hi Vincent,
> >>>>
> >>>> Thanks for your input. I believe that Leadtek card I use is based on
> >>>> cx2388x chip. This is the l4v support page and the card, pay
> attention to
> >>>> revision J detail, is listed as card 82:
> >>>>
> >>>>
> >>>>
> http://git.linuxtv.org/media_tree.git/blob/HEAD:/Documentation/video4linux/CARDLIST.cx88#l83
> >>>>
> >>>> and is being properly recognized as card=82 in the kernel module
> during
> >>>> boot.
> >>>>
> >>>> From the driver change log you sent me we can see some work was done
> for
> >>>> DTV2000H Plus card support which is different one from the one I have.
> >>>>
> >>>> To answer the question about channel 9 ... It's really a roulet with
> >>>> this channel, sometimes its terrible and locks the frontend same as
> GO and
> >>>> GEM but sometimes liveTV is fine. But the recordings are always
> horrible ...
> >>>> go figure. I noticed that 7 is also bad but 7two is perfect. For the
> rest of
> >>>> them the LiveTV works fine and the recording are good quality.
> >>>>
> >>>> Someone, I think it was Nick, asked me about channel tuning setup in
> the
> >>>> backend more specifically about fast channel tuning. I had that
> option set
> >>>> to "Always" but had to switch it to "Never" because of the tuning
> issues I
> >>>> have. This way I can skip the channels I know are broken without
> freezing
> >>>> the frontend in case of auto channel change.
> >>>>
> >>>> It really sucks that, as Karl says at the beginning of the thread,
> >>>> channel import doesn't work properly too for Australia. Can someone
> confirm
> >>>> that this is being fixed? I really can't see any more options for me
> except
> >>>> for channel import after dvbscan.
> >>>>
> >>>> I have an old channels.conf in Mplayer from 13/09/2008 so will try
> that
> >>>> one with Mplayer/xine first before I create a new one.
> >>>>
> >>>> Thanks,
> >>>> Igor
> >>>
> >>>
> >>>
> >>> Ok, I shutdown the mythbackend and did a scan. This is the result of
> the
> >>> initial scan with w_scan (with terrestrial TV channels option only):
> >>>
> >>> $ cat initial-tuning-data.txt
> >>>
> >>>
> #------------------------------------------------------------------------------
> >>> # file automatically generated by w_scan
> >>> # (http://wirbel.htpc-forum.de/w_scan/index2.html)
> >>> #! <w_scan> 20091230 1 0 OFDM AU </w_scan>
> >>>
> >>>
> #------------------------------------------------------------------------------
> >>> # location and provider: <add description here>
> >>> # date (yyyy-mm-dd) : 2012-06-07
> >>> # provided by (opt) : <your name or email here>
> >>> #
> >>> # T[2] <freq> <bw> <fec_hi> <fec_lo> <mod> <tm> <guard> <hi> [#
> comment]
> >>>
> >>>
> #------------------------------------------------------------------------------
> >>> T 177500000 7MHz 3/4 NONE QAM64 8k 1/16 NONE # Seven Network
> >>> T 219500000 7MHz 3/4 NONE QAM64 8k 1/16 NONE # Network TEN
> >>> T 226500000 7MHz 3/4 NONE QAM64 8k 1/16 NONE # ABC Sydney
> >>> T 536625000 7MHz 2/3 NONE QPSK 8k 1/8 NONE # CTV
> >>> T 571500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE # SBS Sydney
> >>>
> >>>
> >>> And for comparison this is what I have in MythTV database:
> >>>
> >>> mysql> select
> mplexid,sourceid,transportid,networkid,frequency,sistandard
> >>> from dtv_multiplex;
> >>>
> +---------+----------+-------------+-----------+-----------+------------+
> >>> | mplexid | sourceid | transportid | networkid | frequency |
> sistandard |
> >>>
> +---------+----------+-------------+-----------+-----------+------------+
> >>> | 1 | 1 | 1538 | 4116 | 219500000 |
> dvb |
> >>> | 2 | 1 | 2 | 57 | 536500000 |
> >>> dvb |
> >>> | 12 | 1 | 768 | 12802 | 571500000 |
> dvb |
> >>> | 11 | 1 | 545 | 4112 | 226500000 | dvb
> >>> |
> >>> | 10 | 1 | 1056 | 4114 | 191500000 |
> dvb |
> >>> | 9 | 1 | 1282 | 4115 | 177500000 | dvb
> >>> |
> >>>
> +---------+----------+-------------+-----------+-----------+------------+
> >>>
> >>> Looks like Myth did even better tuning job than w_scan and found one
> more
> >>> transponder with frequency of 191500000 :). Maybe that's the
> channel9/GO/GEM
> >>> carrier?
> >>>
> >>> After using scan to turn this initial file to channels.conf this is
> what
> >>> I get:
> >>>
> >>>
> >>> $ cat .tzap/channels.conf
> >>> 7
> >>>
> Digital:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:514:1312
> >>> 7 Digital
> >>>
> 1:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:514:1313
> >>>
> >>>
> 7TWO:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:545:546:1314
> >>>
> >>>
> 7mate:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:561:0:1315
> >>> 7
> >>>
> Digital:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:514:1316
> >>>
> >>>
> TV4ME:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:625:626:1319
> >>>
> >>>
> ONE:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:0:1569
> >>> TEN
> >>>
> Digital:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1573
> >>>
> >>>
> ONE:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:0:1575
> >>>
> >>>
> ELEVEN:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:516:681:1576
> >>> ABC News
> >>>
> 24:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2314:0:544
> >>>
> >>>
> ABC1:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:545
> >>> ABC2 /
> >>>
> ABC4:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2307:2308:546
> >>>
> >>>
> ABC1:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:547
> >>>
> >>>
> ABC3:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2311:2312:548
> >>>
> >>>
> TVS:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QPSK:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:100:101:44
> >>> SBS
> >>>
> ONE:571500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:769
> >>> SBS
> >>>
> TWO:571500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:162:83:770
> >>> SBS
> >>>
> 3:571500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:772
> >>> SBS
> >>>
> 4:571500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:773
> >>> SBS
> >>>
> HD:571500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:102:103:774
> >>>
> >>> so no channel9, GO and GEM as we can see.
> >>>
> >>> From this I would say it is obvious that the tuning problem is not in
> >>> MythTV since both scans yield practically same results.. If there is an
> >>> issue with the frequency offset in AUS then both w_scan and Myth
> behave same
> >>> and fail to lock to the offset frequency of +125KHz of our carriers.
> >>>
> >>> What I'm going to do next is add the channel9 frequencies that Vincent
> >>> posted into my channel.conf and check if Mplayer can tune to this
> channels
> >>> at all.
> >>>
> >>> Igor
> >>>
> >>>
> >>>
> >>
> >> Ok, after adding the channel9 frequencies I tried Mplayer and it crashed
> >> when trying to tune to channel9. So same problem as MythTV.
> >>
> >> CONCLUSION: For some reason my card can't tune to channel9 frequency any
> >> more and probably this is related to the dvb driver in Lucid. I didn't
> have
> >> any issues at all with these channels on 8.04 and Myth 0.20. I'll do
> some
> >> investigation and try to find the exact reason. Maybe building the
> latest
> >> v4l modules from git will help.
> >>
> >> Igor
> >
> >
> > Just for completnes, this is my dtv_multiplex table (after adding
> additional
> > 125KHz to the frequencies as suggested by Karl):
> >
> >
> > mysql> select mplexid,sourceid,transportid,networkid,frequency,sistandard
> > from dtv_multiplex;
> > +---------+----------+-------------+-----------+-----------+------------+
> > | mplexid | sourceid | transportid | networkid | frequency | sistandard |
> > +---------+----------+-------------+-----------+-----------+------------+
> > | 1 | 1 | 1538 | 4116 | 219625000 | dvb |
> > | 2 | 1 | 2 | 57 | 536625000 | dvb
> > |
> > | 12 | 1 | 768 | 12802 | 571625000 | dvb |
> > | 11 | 1 | 545 | 4112 | 226625000 | dvb
> |
> > | 10 | 1 | 1056 | 4114 | 191625000 | dvb |
> > | 9 | 1 | 1282 | 4115 | 177625000 | dvb
> |
> > +---------+----------+-------------+-----------+-----------+------------+
> > 6 rows in set (0.00 sec)
> >
> > Would love to see what other Aussies have in their multiplex table.
> >
> > Igor
> >
>
> Sorry I have not analysed the situation in this long lists of posts
> enough or I would be able to answer this myself:
>
> Is the tuning problem with higher frequencies? I have seen it said on
> this list or some myth forum that the higher frequencies are harder to
> tune.
>
> Sorry that's not a solution, but it may point to a problem...
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
Thanks Nick, I'll search for it.
I checked the driver syslog and the result is something I haven't seen
before:
$ dmesg | egrep "cx2388|dvb|DVB|cx88"
[ 18.686379] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
[ 18.686470] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
[ 18.698803] cx88[0]: subsystem: 107d:6f2b, board: WinFast DTV2000 H rev.
J [card=82,autodetected], frontend(s): 1
[ 18.698805] cx88[0]: TV tuner type 63, Radio tuner type -1
[ 18.701199] cx2388x alsa driver version 0.0.7 loaded
[ 18.916524] tuner 0-0043: chip found @ 0x86 (cx88[0])
[ 18.927543] tuner 0-0061: chip found @ 0xc2 (cx88[0])
[ 18.988392] input: cx88 IR (WinFast DTV2000 H rev. as
/devices/pci0000:00/0000:00:14.4/0000:03:07.2/input/input6
[ 18.988524] cx88[0]/2: cx2388x 8802 Driver Manager
[ 18.988555] cx88-mpeg driver manager 0000:03:07.2: PCI INT A -> GSI 21
(level, low) -> IRQ 21
[ 18.988565] cx88[0]/2: found at 0000:03:07.2, rev: 5, irq: 21, latency:
32, mmio: 0xfb000000
[ 18.988572] IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared
IRQs
[ 18.989608] cx8800 0000:03:07.0: PCI INT A -> GSI 21 (level, low) -> IRQ
21
[ 18.989618] cx88[0]/0: found at 0000:03:07.0, rev: 5, irq: 21, latency:
32, mmio: 0xfa000000
[ 18.989630] IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared
IRQs
[ 18.989753] cx88[0]/0: registered device video0 [v4l2]
[ 18.989804] cx88[0]/0: registered device vbi0
[ 18.989852] cx88[0]/0: registered device radio0
[ 19.007549] cx88/2: cx2388x dvb driver version 0.0.7 loaded
[ 19.007554] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 19.007557] cx88[0]/2: subsystem: 107d:6f2b, board: WinFast DTV2000 H
rev. J [card=82]
[ 19.007561] cx88[0]/2: cx2388x based DVB/ATSC card
[ 19.007563] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 19.007791] cx88_audio 0000:03:07.1: PCI INT A -> GSI 21 (level, low) ->
IRQ 21
[ 19.007801] IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared
IRQs
[ 19.007827] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
[ 19.036402] DVB: registering new adapter (cx88[0])
[ 19.036405] DVB: registering adapter 0 frontend 0 (Conexant CX22702
DVB-T)...
[ 28.937066] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937078] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937089] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937097] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937105] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937113] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937129] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937137] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937145] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937153] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937173] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937181] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937189] cx88[0]: irq aud [0x1000] dn_sync*
[ 28.937196] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937212] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 28.937221] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
.
.
and it goes on and on with this IRQ messages. Not sure yet what does this
mean.
Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120607/f0831f59/attachment.html>
More information about the mythtv-users
mailing list