Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24)

  

 
MythTV users RSS feed   Index | Next | Previous | View Threaded


dekarl at spaetfruehstuecken

Jun 3, 2012, 1:38 AM

Post #1 of 24 (1651 views)
Permalink
known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24)
Hi Igor,

I'll write together the issues that I'm aware of for DVB-T in Australia
in case you or other Australians are ready for some patch testing or
even looking for some code hacking to do :-)

As you are on Mythbuntu you can build your own patched packages and even
setup a PPA to share them with fellow testers very easily, see
http://www.mythbuntu.org/wiki/recipes

On 31.05.2012 03:45, Igor Cicimov wrote:
> Before rolling back to 0.23 I'll try to check the card performance
> outside Mythtv. In meantime, any suggestions to solve this highly
> appreciated.

There is at least two known issues with MythTV and DVB-T in AU.

One is that the channel scanner stores the center frequency instead of
the offset frequency of the transports which makes successful tuning
harder depend on the quality of your DVB-T frontend.
http://code.mythtv.org/trac/ticket/9777

Another is that the channel table in MythTV only contains the +125kHz
offset but some transmitters seem to use a +167kHz offset.
https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/frequencytables.cpp#L336
changing the two instances of
DTVModulation::kModulationQAMAuto, 125000, 0);
into
DTVModulation::kModulationQAMAuto, 125000, 167000);
or
DTVModulation::kModulationQAMAuto, 125000, 166667);
might help with that. (A user wanted to test it and report back on IRC
earlier)


With general DVB there was some issue with channel scan that got fixed
for 0.25.

The scanner didn't work well with segmented PAT/SDT tables. This fix has
improved channel scans alot for me on DVB-C.
http://code.mythtv.org/trac/ticket/10054


Some unfixed issues with EIT have patches that you could try.

The scanner sometimes not finding the ONID/TSID has already been
mentioned.
http://code.mythtv.org/trac/ticket/10217
To get at least EIT, should you use that, you can try the patch from
http://code.mythtv.org/trac/ticket/10784
To improve the quality of the EIT data you can also try
http://code.mythtv.org/trac/ticket/10098


And I already worked on the broken channel.conf import, but didn't get
it working and moved on to higher up stuff on my list.

The channel.conf import is known broken for DVB due to not importing
the ONID and TSID.
I have attached a work in progress patch to that ticket, but sadly its
still not working. Might be a starting point for someone who wants to
fix the channel.conf import.
http://code.mythtv.org/trac/ticket/7701


Regards,
Karl
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


icicimov at gmail

Jun 3, 2012, 10:27 PM

Post #2 of 24 (1571 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
Hi Karl,

Thanks a lot for the email mate you saved me lots of time of googling and
collecting information about this issue! And is good to know that I'm not
going nuts and that channel tuning is well known problem in Australia.

I'm at work atm and the stupid IT security policy here doesn't allow me to
open the links you sent me so will have to wait until I get home
tonight. The news about broken import of channels.conf
is particularly upsetting for me since that was the next thing I wanted to
try *sigh*.

The tuner was happily working for 4 years on mythtv 0.20 and mythbuntu 8.04
although the cx88xx module was not recognizing the card properly and needed
little bit of help. After the upgrade to 0.23 all looked good as well but
when I moved to 0.24 the problems started. I guess there have been some
file and database changes during the process that ruined the fun for me. As
you mentioned the frequencies stored in the DB are not exactly correct so
wonder if I can fix this manually by editing the transponders in the
backend config or maybe strait in the database?

At least the channel 10 reception works good so my wife can record her
Masterchef thing and she's not that angry at me like she was 2 days ago :(

Cheers,
Igor

On Sun, Jun 3, 2012 at 6:38 PM, Karl Dietz <dekarl [at] spaetfruehstuecken>wrote:

> Hi Igor,
>
> I'll write together the issues that I'm aware of for DVB-T in Australia
> in case you or other Australians are ready for some patch testing or
> even looking for some code hacking to do :-)
>
> As you are on Mythbuntu you can build your own patched packages and even
> setup a PPA to share them with fellow testers very easily, see
> http://www.mythbuntu.org/wiki/**recipes<http://www.mythbuntu.org/wiki/recipes>
>
> On 31.05.2012 03:45, Igor Cicimov wrote:
>
>> Before rolling back to 0.23 I'll try to check the card performance
>> outside Mythtv. In meantime, any suggestions to solve this highly
>> appreciated.
>>
>
> There is at least two known issues with MythTV and DVB-T in AU.
>
> One is that the channel scanner stores the center frequency instead of
> the offset frequency of the transports which makes successful tuning
> harder depend on the quality of your DVB-T frontend.
> http://code.mythtv.org/trac/**ticket/9777<http://code.mythtv.org/trac/ticket/9777>
>
> Another is that the channel table in MythTV only contains the +125kHz
> offset but some transmitters seem to use a +167kHz offset.
> https://github.com/MythTV/**mythtv/blob/master/mythtv/**libs/libmythtv/**
> frequencytables.cpp#L336<https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/frequencytables.cpp#L336>
> changing the two instances of
> DTVModulation::**kModulationQAMAuto, 125000, 0);
> into
> DTVModulation::**kModulationQAMAuto, 125000, 167000);
> or
> DTVModulation::**kModulationQAMAuto, 125000, 166667);
> might help with that. (A user wanted to test it and report back on IRC
> earlier)
>
>
> With general DVB there was some issue with channel scan that got fixed
> for 0.25.
>
> The scanner didn't work well with segmented PAT/SDT tables. This fix has
> improved channel scans alot for me on DVB-C.
> http://code.mythtv.org/trac/**ticket/10054<http://code.mythtv.org/trac/ticket/10054>
>
>
> Some unfixed issues with EIT have patches that you could try.
>
> The scanner sometimes not finding the ONID/TSID has already been
> mentioned.
> http://code.mythtv.org/trac/**ticket/10217<http://code.mythtv.org/trac/ticket/10217>
> To get at least EIT, should you use that, you can try the patch from
> http://code.mythtv.org/trac/**ticket/10784<http://code.mythtv.org/trac/ticket/10784>
> To improve the quality of the EIT data you can also try
> http://code.mythtv.org/trac/**ticket/10098<http://code.mythtv.org/trac/ticket/10098>
>
>
> And I already worked on the broken channel.conf import, but didn't get
> it working and moved on to higher up stuff on my list.
>
> The channel.conf import is known broken for DVB due to not importing
> the ONID and TSID.
> I have attached a work in progress patch to that ticket, but sadly its
> still not working. Might be a starting point for someone who wants to
> fix the channel.conf import.
> http://code.mythtv.org/trac/**ticket/7701<http://code.mythtv.org/trac/ticket/7701>
>
>
> Regards,
> Karl
> ______________________________**_________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>


jyavenard at gmail

Jun 4, 2012, 1:39 AM

Post #3 of 24 (1566 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken> wrote:

> One is that the channel scanner stores the center frequency instead of
> the offset frequency of the transports which makes successful tuning
> harder depend on the quality of your DVB-T frontend.
> http://code.mythtv.org/trac/ticket/9777

This issue is mostly specific to the DVB-T adapter used and none of
them will behave the same.

The better solution is to stick with DVB-T adapters known to work with MythTV
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


icicimov at gmail

Jun 4, 2012, 6:29 AM

Post #4 of 24 (1567 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Mon, Jun 4, 2012 at 6:39 PM, Jean-Yves Avenard <jyavenard [at] gmail>wrote:

> On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken> wrote:
>
> > One is that the channel scanner stores the center frequency instead of
> > the offset frequency of the transports which makes successful tuning
> > harder depend on the quality of your DVB-T frontend.
> > http://code.mythtv.org/trac/ticket/9777
>
> This issue is mostly specific to the DVB-T adapter used and none of
> them will behave the same.
>

Agree, and this one worked fine on 0.20.


> The better solution is to stick with DVB-T adapters known to work with
> MythTV
>

Such as?

Looks like there should be a list of tuners best supported per MythTV
release :)


seven at seven

Jun 4, 2012, 2:32 PM

Post #5 of 24 (1561 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On 4 June 2012 23:29, Igor Cicimov <icicimov [at] gmail> wrote:

> On Mon, Jun 4, 2012 at 6:39 PM, Jean-Yves Avenard <jyavenard [at] gmail>wrote:
>
>> On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken> wrote:
>>
>> > One is that the channel scanner stores the center frequency instead of
>> > the offset frequency of the transports which makes successful tuning
>> > harder depend on the quality of your DVB-T frontend.
>> > http://code.mythtv.org/trac/ticket/9777
>>
>> This issue is mostly specific to the DVB-T adapter used and none of
>> them will behave the same.
>>
>
> Agree, and this one worked fine on 0.20.
>
>
>> The better solution is to stick with DVB-T adapters known to work with
>> MythTV
>>
>
> Such as?
>
> Looks like there should be a list of tuners best supported per MythTV
> release :)
>
>
> The HDHR DVB Version seems to work well enough in Aus.

The last time I rescanned I had no issues.

Cheers,

Anthony


icicimov at gmail

Jun 4, 2012, 6:59 PM

Post #6 of 24 (1552 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Tue, Jun 5, 2012 at 7:32 AM, Anthony Giggins
<seven [at] seven>wrote:

>
>
> On 4 June 2012 23:29, Igor Cicimov <icicimov [at] gmail> wrote:
>
>> On Mon, Jun 4, 2012 at 6:39 PM, Jean-Yves Avenard <jyavenard [at] gmail>wrote:
>>
>>> On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken> wrote:
>>>
>>> > One is that the channel scanner stores the center frequency instead of
>>> > the offset frequency of the transports which makes successful tuning
>>> > harder depend on the quality of your DVB-T frontend.
>>> > http://code.mythtv.org/trac/ticket/9777
>>>
>>> This issue is mostly specific to the DVB-T adapter used and none of
>>> them will behave the same.
>>>
>>
>> Agree, and this one worked fine on 0.20.
>>
>>
>>> The better solution is to stick with DVB-T adapters known to work with
>>> MythTV
>>>
>>
>> Such as?
>>
>> Looks like there should be a list of tuners best supported per MythTV
>> release :)
>>
>>
>> The HDHR DVB Version seems to work well enough in Aus.
>
> The last time I rescanned I had no issues.
>
> Cheers,
>
> Anthony
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
Hi Anthony,

Thanks for the reply it's good to know that. The point I want to make here
is that everything is relative :). If someone asked me couple of weeks ago
while I was still on 0.20 would I recommend my tuner card for DVB-T on
MythTV I would have said YES. But now when I moved to 0.24 and 0.25 I can't
say that can I ?!

In your case I would say "HDHR DVB Version seems to work well enough in Aus
in the CURRENT MythTV version you are running on your box". As you can see
from my experience that can change in 0.27 lets say due to some DB table
change or what ever.

Cheers,
Igor


seven at seven

Jun 4, 2012, 7:26 PM

Post #7 of 24 (1556 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On 5 June 2012 11:59, Igor Cicimov <icicimov [at] gmail> wrote:

> On Tue, Jun 5, 2012 at 7:32 AM, Anthony Giggins <
> seven [at] seven> wrote:
>
>>
>>
>> On 4 June 2012 23:29, Igor Cicimov <icicimov [at] gmail> wrote:
>>
>>> On Mon, Jun 4, 2012 at 6:39 PM, Jean-Yves Avenard <jyavenard [at] gmail>wrote:
>>>
>>>> On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken> wrote:
>>>>
>>>> > One is that the channel scanner stores the center frequency instead of
>>>> > the offset frequency of the transports which makes successful tuning
>>>> > harder depend on the quality of your DVB-T frontend.
>>>> > http://code.mythtv.org/trac/ticket/9777
>>>>
>>>> This issue is mostly specific to the DVB-T adapter used and none of
>>>> them will behave the same.
>>>>
>>>
>>> Agree, and this one worked fine on 0.20.
>>>
>>>
>>>> The better solution is to stick with DVB-T adapters known to work with
>>>> MythTV
>>>>
>>>
>>> Such as?
>>>
>>> Looks like there should be a list of tuners best supported per MythTV
>>> release :)
>>>
>>>
>>> The HDHR DVB Version seems to work well enough in Aus.
>>
>> The last time I rescanned I had no issues.
>>
>> Cheers,
>>
>> Anthony
>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users [at] mythtv
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>>
> Hi Anthony,
>
> Thanks for the reply it's good to know that. The point I want to make here
> is that everything is relative :). If someone asked me couple of weeks ago
> while I was still on 0.20 would I recommend my tuner card for DVB-T on
> MythTV I would have said YES. But now when I moved to 0.24 and 0.25 I can't
> say that can I ?!
>
> In your case I would say "HDHR DVB Version seems to work well enough in
> Aus in the CURRENT MythTV version you are running on your box". As you can
> see from my experience that can change in 0.27 lets say due to some DB
> table change or what ever.
>
> Cheers,
> Igor
>
> Sure but what else was changed when you sent from 0.20 to 0.24 & 0.25 ?
surely your not running the same OS version that 0.20 was running on?

I've always had better luck scanning on my HDHR rather then my PCI Dvico
DVB-T Plus http://www.octapc.com.au/images/p_dvbtplus.jpg

Cheers,

Anthony


icicimov at gmail

Jun 4, 2012, 8:57 PM

Post #8 of 24 (1552 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Tue, Jun 5, 2012 at 12:26 PM, Anthony Giggins <seven [at] seven
> wrote:

>
>
> On 5 June 2012 11:59, Igor Cicimov <icicimov [at] gmail> wrote:
>
>> On Tue, Jun 5, 2012 at 7:32 AM, Anthony Giggins <
>> seven [at] seven> wrote:
>>
>>>
>>>
>>> On 4 June 2012 23:29, Igor Cicimov <icicimov [at] gmail> wrote:
>>>
>>>> On Mon, Jun 4, 2012 at 6:39 PM, Jean-Yves Avenard <jyavenard [at] gmail>wrote:
>>>>
>>>>> On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken>
>>>>> wrote:
>>>>>
>>>>> > One is that the channel scanner stores the center frequency instead
>>>>> of
>>>>> > the offset frequency of the transports which makes successful tuning
>>>>> > harder depend on the quality of your DVB-T frontend.
>>>>> > http://code.mythtv.org/trac/ticket/9777
>>>>>
>>>>> This issue is mostly specific to the DVB-T adapter used and none of
>>>>> them will behave the same.
>>>>>
>>>>
>>>> Agree, and this one worked fine on 0.20.
>>>>
>>>>
>>>>> The better solution is to stick with DVB-T adapters known to work with
>>>>> MythTV
>>>>>
>>>>
>>>> Such as?
>>>>
>>>> Looks like there should be a list of tuners best supported per MythTV
>>>> release :)
>>>>
>>>>
>>>> The HDHR DVB Version seems to work well enough in Aus.
>>>
>>> The last time I rescanned I had no issues.
>>>
>>> Cheers,
>>>
>>> Anthony
>>>
>>>
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users [at] mythtv
>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>>
>> Hi Anthony,
>>
>> Thanks for the reply it's good to know that. The point I want to make
>> here is that everything is relative :). If someone asked me couple of weeks
>> ago while I was still on 0.20 would I recommend my tuner card for DVB-T on
>> MythTV I would have said YES. But now when I moved to 0.24 and 0.25 I can't
>> say that can I ?!
>>
>> In your case I would say "HDHR DVB Version seems to work well enough in
>> Aus in the CURRENT MythTV version you are running on your box". As you can
>> see from my experience that can change in 0.27 lets say due to some DB
>> table change or what ever.
>>
>> Cheers,
>> Igor
>>
>> Sure but what else was changed when you sent from 0.20 to 0.24 & 0.25 ?
> surely your not running the same OS version that 0.20 was running on?
>
> I've always had better luck scanning on my HDHR rather then my PCI Dvico
> DVB-T Plus http://www.octapc.com.au/images/p_dvbtplus.jpg
>
> Cheers,
>
> Anthony
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
This is my exact upgrade path:

1. From Mythbuntu 8.04 and MythTV 0.20 to Mythbuntu 10.04 and MythTV 0.23
to
- Here all worked fine and I even noticed slight improvement in tuning and
LiveTV quality

2. From MythTV 0.23 to MythTV 0.24 (Mythbuntu 10.04)
- Here the tuning brakes

3. From MythTV 0.24 to MythTV 0.25 (Mythbuntu 10.04)
- Same

Igor


nick.rout at gmail

Jun 5, 2012, 12:21 AM

Post #9 of 24 (1550 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Tue, Jun 5, 2012 at 3:57 PM, Igor Cicimov <icicimov [at] gmail> wrote:
>
>
> On Tue, Jun 5, 2012 at 12:26 PM, Anthony Giggins
> <seven [at] seven> wrote:
>>
>>
>>
>> On 5 June 2012 11:59, Igor Cicimov <icicimov [at] gmail> wrote:
>>>
>>> On Tue, Jun 5, 2012 at 7:32 AM, Anthony Giggins
>>> <seven [at] seven> wrote:
>>>>
>>>>
>>>>
>>>> On 4 June 2012 23:29, Igor Cicimov <icicimov [at] gmail> wrote:
>>>>>
>>>>> On Mon, Jun 4, 2012 at 6:39 PM, Jean-Yves Avenard <jyavenard [at] gmail>
>>>>> wrote:
>>>>>>
>>>>>> On 3 June 2012 18:38, Karl Dietz <dekarl [at] spaetfruehstuecken>
>>>>>> wrote:
>>>>>>
>>>>>> > One is that the channel scanner stores the center frequency instead
>>>>>> > of
>>>>>> > the offset frequency of the transports which makes successful tuning
>>>>>> > harder depend on the quality of your DVB-T frontend.
>>>>>> > http://code.mythtv.org/trac/ticket/9777
>>>>>>
>>>>>> This issue is mostly specific to the DVB-T adapter used and none of
>>>>>> them will behave the same.
>>>>>
>>>>>
>>>>>   Agree, and this one worked fine on 0.20.
>>>>>
>>>>>>
>>>>>> The better solution is to stick with DVB-T adapters known to work with
>>>>>> MythTV
>>>>>
>>>>>
>>>>>  Such as?
>>>>>
>>>>>  Looks like there should be a list of tuners best supported per MythTV
>>>>> release :)
>>>>>
>>>>>
>>>> The HDHR DVB Version seems to work well enough in Aus.
>>>>
>>>> The last time I rescanned I had no issues.
>>>>
>>>> Cheers,
>>>>
>>>> Anthony
>>>>
>>>>
>>>> _______________________________________________
>>>> mythtv-users mailing list
>>>> mythtv-users [at] mythtv
>>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>>
>>>
>>> Hi Anthony,
>>>
>>> Thanks for the reply it's good to know that. The point I want to make
>>> here is that everything is relative :). If someone asked me couple of weeks
>>> ago while I was still on 0.20 would I recommend my tuner card for DVB-T on
>>> MythTV I would have said YES. But now when I moved to 0.24 and 0.25 I can't
>>> say that can I ?!
>>>
>>> In your case I would say "HDHR DVB Version seems to work well enough in
>>> Aus in the CURRENT MythTV version you are running on your box". As you can
>>> see from my experience that can change in 0.27 lets say due to some DB table
>>> change or what ever.
>>>
>>> Cheers,
>>> Igor
>>>
>> Sure but what else was changed when you sent from 0.20 to 0.24 & 0.25 ?
>> surely your not running the same OS version that 0.20 was running on?
>>
>> I've always had better luck scanning on my HDHR rather then my PCI Dvico
>> DVB-T Plus http://www.octapc.com.au/images/p_dvbtplus.jpg
>>
>> Cheers,
>>
>> Anthony
>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users [at] mythtv
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>
> This is my exact upgrade path:
>
> 1. From Mythbuntu 8.04 and MythTV 0.20 to Mythbuntu 10.04 and MythTV 0.23
> to
> - Here all worked fine and I even noticed slight improvement in tuning and
> LiveTV quality
>
> 2. From MythTV 0.23 to MythTV 0.24 (Mythbuntu 10.04)
> - Here the tuning brakes
>
> 3. From MythTV 0.24 to MythTV 0.25 (Mythbuntu 10.04)
> - Same

So sorry but I haven't followed all your posts - is your problem
scanning (if so why? you still have your dB and all your channel info)
or tuning? If tuning is it only in livetv, or only in recordings, or
both?

If there is a difference between live and recordings, do you have fast
tuning for livetv activated?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jyavenard at gmail

Jun 5, 2012, 1:01 AM

Post #10 of 24 (1544 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On 5 June 2012 13:57, Igor Cicimov <icicimov [at] gmail> wrote:

> This is my exact upgrade path:
>
> 1. From Mythbuntu 8.04 and MythTV 0.20 to Mythbuntu 10.04 and MythTV 0.23
> to
> - Here all worked fine and I even noticed slight improvement in tuning and
> LiveTV quality
>
> 2. From MythTV 0.23 to MythTV 0.24 (Mythbuntu 10.04)
> - Here the tuning brakes
>
> 3. From MythTV 0.24 to MythTV 0.25 (Mythbuntu 10.04)
> - Same
>
> Igor

Sigh...

Of course, something must have become broken in MythTV... What else could it be.

There has obviously been no upgrade whatsoever to the DVB-T drivers in
the linux kernel in the past 4 years.
The change from ubuntu 8.04 to ubuntu 10.04 was of course a minor one,
and the only possible explanation on why scanning worked back over 4
years ago is due to change to the way mythtv scan channels..

Interestingly, if you look at mythtv changes history, you would have
found that the channel scanner is probably the part of myth that has
changed the least in all those years, changes being mostly about
adding support for new frequencies...
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


nick.rout at gmail

Jun 5, 2012, 1:19 AM

Post #11 of 24 (1548 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Tue, Jun 5, 2012 at 8:01 PM, Jean-Yves Avenard <jyavenard [at] gmail> wrote:
> On 5 June 2012 13:57, Igor Cicimov <icicimov [at] gmail> wrote:
>
>> This is my exact upgrade path:
>>
>> 1. From Mythbuntu 8.04 and MythTV 0.20 to Mythbuntu 10.04 and MythTV 0.23
>> to
>> - Here all worked fine and I even noticed slight improvement in tuning and
>> LiveTV quality
>>
>> 2. From MythTV 0.23 to MythTV 0.24 (Mythbuntu 10.04)
>> - Here the tuning brakes
>>
>> 3. From MythTV 0.24 to MythTV 0.25 (Mythbuntu 10.04)
>> - Same
>>
>> Igor
>
> Sigh...
>
> Of course, something must have become broken in MythTV... What else could it be.
>
> There has obviously been no upgrade whatsoever to the DVB-T drivers in
> the linux kernel in the past 4 years.
> The change from ubuntu 8.04 to ubuntu 10.04 was of course a minor one,
> and the only possible explanation on why scanning worked back over 4
> years ago is due to change to the way mythtv scan channels..
>
> Interestingly, if you look at mythtv changes history, you would have
> found that the channel scanner is probably the part of myth that has
> changed the least in all those years, changes being mostly about
> adding support for new frequencies...

All of which makes it intriguing as to why lurking this list and
mythbuntu forums seems to indicate more and more problems with
scanning channels as time (and releases) goes on.

Everyone says "not me" - but there is something going on, and it
certainly is frustrating to a lot of people.

Dissecting a multivariable problem to find which change in variable
broke what and when is a real difficulty I know, but at some stage it
needs to be sorted. (Which is easy to say...)
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


icicimov at gmail

Jun 5, 2012, 9:47 PM

Post #12 of 24 (1541 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Tue, Jun 5, 2012 at 6:19 PM, Nick Rout <nick.rout [at] gmail> wrote:

> On Tue, Jun 5, 2012 at 8:01 PM, Jean-Yves Avenard <jyavenard [at] gmail>
> wrote:
> > On 5 June 2012 13:57, Igor Cicimov <icicimov [at] gmail> wrote:
> >
> >> This is my exact upgrade path:
> >>
> >> 1. From Mythbuntu 8.04 and MythTV 0.20 to Mythbuntu 10.04 and MythTV
> 0.23
> >> to
> >> - Here all worked fine and I even noticed slight improvement in tuning
> and
> >> LiveTV quality
> >>
> >> 2. From MythTV 0.23 to MythTV 0.24 (Mythbuntu 10.04)
> >> - Here the tuning brakes
> >>
> >> 3. From MythTV 0.24 to MythTV 0.25 (Mythbuntu 10.04)
> >> - Same
> >>
> >> Igor
> >
> > Sigh...
> >
> > Of course, something must have become broken in MythTV... What else
> could it be.
> >
> > There has obviously been no upgrade whatsoever to the DVB-T drivers in
> > the linux kernel in the past 4 years.
> > The change from ubuntu 8.04 to ubuntu 10.04 was of course a minor one,
> > and the only possible explanation on why scanning worked back over 4
> > years ago is due to change to the way mythtv scan channels..
> >
> > Interestingly, if you look at mythtv changes history, you would have
> > found that the channel scanner is probably the part of myth that has
> > changed the least in all those years, changes being mostly about
> > adding support for new frequencies...
>
> All of which makes it intriguing as to why lurking this list and
> mythbuntu forums seems to indicate more and more problems with
> scanning channels as time (and releases) goes on.
>
> Everyone says "not me" - but there is something going on, and it
> certainly is frustrating to a lot of people.
>
> Dissecting a multivariable problem to find which change in variable
> broke what and when is a real difficulty I know, but at some stage it
> needs to be sorted. (Which is easy to say...)
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

Guys,

Please don't take this as attack on myth I never had any intention doing
that and I never will. I love myth and a problem tuning couple of channels
will not stop me using this great product. There are lots of awesome stuff
one can do with myth and it comes for free! My thread literally started
with the question "Does anyone know about any changes in MythTV or cx88-dvb
kernel driver that might affect the tuning of this card". I was not
winging, accusing or complaining I simply asked for other peoples
experience. And from couple of threads I've been following came out that
people in general have tuning problems with Leadtek WinFast DTV2000 H (my
is revision J).

Just for the record, editing the frequencies in the dtv_multiplex table ie
adding 125KHz to the transport, didn't make any difference for me. The
channels that have tuned fine are still tuning fine and the ones that
didn't still suck. This channels like GO and GEM can't acquire a proper
lock, come up with horrible picture for a second and lock the
frontend completely.

Igor


vincent.mcintyre at gmail

Jun 6, 2012, 3:03 AM

Post #13 of 24 (1539 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On 6/6/12, Igor Cicimov <icicimov [at] gmail> wrote:

>
> Please don't take this as attack on myth I never had any intention doing
> that and I never will. I love myth and a problem tuning couple of channels
> will not stop me using this great product. There are lots of awesome stuff
> one can do with myth and it comes for free! My thread literally started
> with the question "Does anyone know about any changes in MythTV or cx88-dvb
> kernel driver that might affect the tuning of this card". I was not
> winging, accusing or complaining I simply asked for other peoples
> experience. And from couple of threads I've been following came out that
> people in general have tuning problems with Leadtek WinFast DTV2000 H (my
> is revision J).
>
> Just for the record, editing the frequencies in the dtv_multiplex table ie
> adding 125KHz to the transport, didn't make any difference for me. The
> channels that have tuned fine are still tuning fine and the ones that
> didn't still suck. This channels like GO and GEM can't acquire a proper
> lock, come up with horrible picture for a second and lock the
> frontend completely.
>

In my area these chanels are in the same multiplex as channel 9 (i.e.
'good' channels) so should be at the same carrier frequency. Are there
other misbehaving channels?
FWIW this is from my channels.conf (scanned with w_scan, July 2011).

% grep Nine channels.conf
NINE DIGITAL(Nine
Network):191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:519:720:1057
GEM(Nine Network):191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:0:1058
GO!(Nine Network):191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:517:700:1059


It may be worth asking about this on the linux-media list as there
were some changes specifically to do with tuning in Australia in the
last couple of years that affected my cards (which use
tuners-xc2028.c), eg [1]. There may still be issues with other
drivers.
You can look at the history of the driver yourself at [2] - in fact a
quick squiz shows explicit mention of something that looks like it
could be your card.

You may need to be prepared to run tests with w_scan etc and build the
latest drivers to get this fixed. And precise hardware ids, see lspci
etc below. Adventure calls!

For the record - I think my tuners are working ok now (myth 0.24-fixes
and ubuntu lucid) but in the past I have had to create a channels.conf
and import it. I'll try some tests when I upgrade to 0.25.

% lspci -kv
04:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885
PCI Video and Audio Decoder (rev 02)
Subsystem: DViCO Corporation Device db78
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at 90000000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] Power Management version 2
Capabilities: [90] Vital Product Data <?>
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [200] Virtual Channel <?>
Kernel driver in use: cx23885
Kernel modules: cx23885

% modinfo cx23885|grep version
srcversion: 8B372C18D81D94481D3C03E
vermagic: 2.6.32-41-generic SMP mod_unload modversions 586

(Dvico FusionHDTV, rev 2 I think)

% lsusb
Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)

(One PCI card with two USB tuners, also happens to use cx23885)

Cheers
Vince

[1] http://git.linuxtv.org/media_tree.git/commit/7f2199c03b4946f1b79514b3411e3dbf130a6bba
[2] http://git.linuxtv.org/media_tree.git/history/HEAD:/drivers/media/video/cx88
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


vincent.mcintyre at gmail

Jun 6, 2012, 3:22 AM

Post #14 of 24 (1523 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
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
http://www.mythtv.org/mailman/listinfo/mythtv-users


icicimov at gmail

Jun 6, 2012, 4:39 PM

Post #15 of 24 (1514 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre <vincent.mcintyre [at] gmail
> 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
> 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


icicimov at gmail

Jun 6, 2012, 5:59 PM

Post #16 of 24 (1516 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, Jun 7, 2012 at 9:39 AM, Igor Cicimov <icicimov [at] gmail> wrote:

> On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre <
> vincent.mcintyre [at] gmail> 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
>> 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


icicimov at gmail

Jun 6, 2012, 6:16 PM

Post #17 of 24 (1512 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, Jun 7, 2012 at 10:59 AM, Igor Cicimov <icicimov [at] gmail> wrote:

> On Thu, Jun 7, 2012 at 9:39 AM, Igor Cicimov <icicimov [at] gmail> wrote:
>
>> On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre <
>> vincent.mcintyre [at] gmail> 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
>>> 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


icicimov at gmail

Jun 6, 2012, 6:23 PM

Post #18 of 24 (1509 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, Jun 7, 2012 at 11:16 AM, Igor Cicimov <icicimov [at] gmail> wrote:

> On Thu, Jun 7, 2012 at 10:59 AM, Igor Cicimov <icicimov [at] gmail> wrote:
>
>> On Thu, Jun 7, 2012 at 9:39 AM, Igor Cicimov <icicimov [at] gmail> wrote:
>>
>>> On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre <
>>> vincent.mcintyre [at] gmail> 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
>>>> 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


nick.rout at gmail

Jun 6, 2012, 11:20 PM

Post #19 of 24 (1504 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, Jun 7, 2012 at 1:23 PM, Igor Cicimov <icicimov [at] gmail> wrote:
> On Thu, Jun 7, 2012 at 11:16 AM, Igor Cicimov <icicimov [at] gmail> wrote:
>>
>> On Thu, Jun 7, 2012 at 10:59 AM, Igor Cicimov <icicimov [at] gmail> wrote:
>>>
>>> On Thu, Jun 7, 2012 at 9:39 AM, Igor Cicimov <icicimov [at] gmail> wrote:
>>>>
>>>> On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre
>>>> <vincent.mcintyre [at] gmail> 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
>>>>> 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
http://www.mythtv.org/mailman/listinfo/mythtv-users


icicimov at gmail

Jun 7, 2012, 2:54 AM

Post #20 of 24 (1502 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, Jun 7, 2012 at 4:20 PM, Nick Rout <nick.rout [at] gmail> wrote:

> On Thu, Jun 7, 2012 at 1:23 PM, Igor Cicimov <icicimov [at] gmail> wrote:
> > On Thu, Jun 7, 2012 at 11:16 AM, Igor Cicimov <icicimov [at] gmail>
> wrote:
> >>
> >> On Thu, Jun 7, 2012 at 10:59 AM, Igor Cicimov <icicimov [at] gmail>
> wrote:
> >>>
> >>> On Thu, Jun 7, 2012 at 9:39 AM, Igor Cicimov <icicimov [at] gmail>
> wrote:
> >>>>
> >>>> On Wed, Jun 6, 2012 at 8:22 PM, Vincent McIntyre
> >>>> <vincent.mcintyre [at] gmail> 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
> >>>>> 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
> >>>
> >>>
> #------------------------------------------------------------------------------
> >>>
> >>>
> #------------------------------------------------------------------------------
> 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
> |
> |
> > +---------+----------+-------------+-----------+-----------+------------+
> > 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
> 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


vincent.mcintyre at gmail

Jun 7, 2012, 4:05 AM

Post #21 of 24 (1496 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
...deletia...

>
> 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.
>

I'm in Sydney too and this is what I have in my table.
I am not seeing any problems recording or viewing livetv with these.

mysql> select mplexid,sourceid,transportid,networkid,frequency,sistandard
from dtv_multiplex;
+---------+----------+-------------+-----------+-----------+------------+
| mplexid | sourceid | transportid | networkid | frequency | sistandard |
+---------+----------+-------------+-----------+-----------+------------+
| 7 | 1 | 1056 | NULL | 191625000 | |
| 8 | 1 | 1282 | NULL | 177500000 | |
| 9 | 1 | 1538 | NULL | 219500000 | |
| 10 | 1 | 545 | NULL | 226500000 | |
| 11 | 1 | 2 | NULL | 536625000 | |
| 12 | 1 | 768 | NULL | 571500000 | |
+---------+----------+-------------+-----------+-----------+------------+

Note that not all channels have the 125kHz offset compared to your
original table.
For the Nine multiplex (mplexid 7) 191.625MHz is what the ACMA
has in its list of frequencies for the Artarmon transmitter.
www.acma.gov.au/webwr/_assets/main/lib100059/tv_6.pdf

The others are (these are the closest to what you list)
TEN 219.5
SBS 571.5
ABC 226.5
SEVEN 177.5

Can't find a reference for transportid 2, which we both have at 536.625MHz.
It shows a callsign of TVS in my scans.

Not sure why sistandard is empty and networkid is NULL.
I'm starting to doubt I scanned with mythtv but imported instead.

Hope this helps a little.
Vince
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


peter_s_d at fastmail

Jun 7, 2012, 6:29 AM

Post #22 of 24 (1488 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, 7 Jun 2012, Igor Cicimov wrote:

[big snip]

> 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

SOME Aus stations use a 125 kHz offset. In Melbourne it is Ch 9 and SBS.
If you want it to work with version 0.24, and maybe others, scan, then go
to "edit transports" and add 125000 to the offending entries. Reception
improved dramatically for me when I did that.

While you are at it, mark the ABC as add free, and delete duplicate
transports.

After that write it down somewhere so that you will remember to do it
again next time you have to set anything up.

--
blind Pete
Sig goes here...


icicimov at gmail

Jun 12, 2012, 6:17 PM

Post #23 of 24 (1371 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Thu, Jun 7, 2012 at 11:29 PM, blind Pete <peter_s_d [at] fastmail>wrote:

> **
>
> On Thu, 7 Jun 2012, Igor Cicimov wrote:
>
>
> [big snip]
>
>
> > 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
>
>
> SOME Aus stations use a 125 kHz offset. In Melbourne it is Ch 9 and SBS.
>
> If you want it to work with version 0.24, and maybe others, scan, then go
>
> to "edit transports" and add 125000 to the offending entries. Reception
>
> improved dramatically for me when I did that.
>
>
> While you are at it, mark the ABC as add free, and delete duplicate
>
> transports.
>
>
> After that write it down somewhere so that you will remember to do it
>
> again next time you have to set anything up.
>
>
> --
>
> blind Pete
>
> Sig goes here...
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
Thanks Vincente and Pete, I'll try to do as you suggested when I get some
free time and come back with the results.

Igor


icicimov at gmail

Jun 17, 2012, 7:39 PM

Post #24 of 24 (1282 views)
Permalink
Re: known issues related to DVB-T in Australia (was: Channel tuning broken in 0.24) [In reply to]
On Wed, Jun 13, 2012 at 11:17 AM, Igor Cicimov <icicimov [at] gmail> wrote:

> On Thu, Jun 7, 2012 at 11:29 PM, blind Pete <peter_s_d [at] fastmail>wrote:
>
>> **
>>
>> On Thu, 7 Jun 2012, Igor Cicimov wrote:
>>
>>
>> [big snip]
>>
>>
>> > 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
>>
>>
>> SOME Aus stations use a 125 kHz offset. In Melbourne it is Ch 9 and SBS.
>>
>> If you want it to work with version 0.24, and maybe others, scan, then go
>>
>> to "edit transports" and add 125000 to the offending entries. Reception
>>
>> improved dramatically for me when I did that.
>>
>>
>> While you are at it, mark the ABC as add free, and delete duplicate
>>
>> transports.
>>
>>
>> After that write it down somewhere so that you will remember to do it
>>
>> again next time you have to set anything up.
>>
>>
>> --
>>
>> blind Pete
>>
>> Sig goes here...
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users [at] mythtv
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>>
> Thanks Vincente and Pete, I'll try to do as you suggested when I get some
> free time and come back with the results.
>
> Igor
>

Ok, just a feedback on this one. I left only the transport for channel
9/Go/Gem with 125KHz offset, deleted all the channels and did a full scan
again. This time I got a lock on all the channels including 9,Go and Gem.
I'm on Lucid kernel 2.6.32-41 atm and the latest 0.25-fixes update.

As an additional note, I had to choose the Slim profile eventually to have
everything working perfectly. With the other higher end profiles I had A/V
stutter in LiveTv on some channels (HD ones usually) or/and recordings.

Thanks,
Igor

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.