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

Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk

 

 

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


stuart at tase

Mar 9, 2006, 4:14 AM

Post #1 of 6 (1874 views)
Permalink
Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk

On Thursday 09 March 2006 00:56, mythtv [at] cvs wrote:
> Fixes #744. Switch over to DVBSignalMonitor based channel scan from
> SIParser based.
>
> This may cause some problems in DVB land with the channel scan.

First off, nice work ... it seems to work better than the siparser based
scanning and is much more informative.

A few problems though, no doubt Stuart A or Janne will be able to discover the
exact reasons behind them but I'll give a users perspective on them.

For each transport I get the following error
"Timeout Scanning Transport ID 4102 -- no tables"
although it appears to find the channels/tables just fine.

I also get the error:
"Found channel, but it doesn't match existing tsid. You may wish to delete
exis ...." (it disappears off-screen)

I get a lot of bogus channels being added, all of which follow the same
pattern:
Adding C2#5 0-0 as 2#5 on Transport ID 8200 (0)
Adding C2#6 0-0 as 2#6 on Transport ID 8200 (0)

Lastly I've noticed that it is duplicating all 6 multiplexes to the
dtv_multiplex table for every transport scanned. That's 42 duplicate
multiplexes added for each scan. Only the first, original, six are actually
used in the channel table, but then it isn't finding any new channels.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuart at tase

Mar 9, 2006, 4:27 AM

Post #2 of 6 (1767 views)
Permalink
Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk [In reply to]

On Thursday 09 March 2006 12:14, Stuart Morgan wrote:
> Lastly I've noticed that it is duplicating all 6 multiplexes to the
> dtv_multiplex table for every transport scanned. That's 42 duplicate
> multiplexes added for each scan. Only the first, original, six are actually
> used in the channel table, but then it isn't finding any new channels.

Actually looking at this closer it's adding two copies of each multiplex one
with NULL values in place of the important data. e.g. Inversion, Fec, Guard
Interval etc and a different, incorrect frequency.

So 84 added with each scan and all duplicates of the pre-existing ones.

| 90 | 1 | 24576 | 9018 | 778000000 | NULL |
NULL | NULL | NULL | NULL | NULL
| NULL | NULL | NULL | 0 | NULL
| NULL | NULL | dvb |
33 | 2006-03-09 12:09:53 |
| 89 | 1 | 24576 | 9018 | 642000000 | ÿ |
NULL | NULL | NULL | NULL | 8
| 3/4 | 2 | 1/32 | 0 | qam_16
| n | 3/4 | dvb |
33 | 2006-03-09 12:09:53 |
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuart at tase

Mar 9, 2006, 4:36 AM

Post #3 of 6 (1790 views)
Permalink
Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk [In reply to]

On Thursday 09 March 2006 12:14, Stuart Morgan wrote:
> That's 42 duplicate multiplexes added for each scan.
....
> So 84 added with each scan and all duplicates of the pre-existing ones.

Err, those figures should be 36 and 72. Not 42 and 84 ... 6x6 not 6x7. This
isn't my week!
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


danielk at cuymedia

Mar 9, 2006, 7:51 AM

Post #4 of 6 (1758 views)
Permalink
Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk [In reply to]

On Thu, 2006-03-09 at 12:14 +0000, Stuart Morgan wrote:

> For each transport I get the following error
> "Timeout Scanning Transport ID 4102 -- no tables"
> although it appears to find the channels/tables just fine.
Hmm, this would indicate that it doesn't think it has found all the
channels on that transport. In HandleDVBDBInsertion(), waitingForTables
gets set to false once all the tables have been found, this message
should only be printed if we timeout before this variable is set.

But perhaps this isn't an error?

Is this only printed for transports where the MythTV scan does not
insert any channels?

> I also get the error:
> "Found channel, but it doesn't match existing tsid. You may wish to delete
> exis ...." (it disappears off-screen)
You should be able to scroll that window. The console message will provide
a little more info, but it is basically telling you that there are some
bogus dtv_multiplex entries and you should probably delete them and do a
full scan to get less bogus ones.

> I get a lot of bogus channels being added, all of which follow the same
> pattern:
> Adding C2#5 0-0 as 2#5 on Transport ID 8200 (0)
> Adding C2#6 0-0 as 2#6 on Transport ID 8200 (0)
This happens when it can't find any DVB/ATSC tables, but there are
programs listed in the MPEG PAT table. This is used to detect the
raw MPEG programs sent by most cable providers in the US. Have you
tried tuning to one of these channels?

> Lastly I've noticed that it is duplicating all 6 multiplexes to the
> dtv_multiplex table for every transport scanned. That's 42 duplicate
> multiplexes added for each scan. Only the first, original, six are actually
> used in the channel table, but then it isn't finding any new channels.
This may be related to that "Found channel..." message you saw earlier,
try deleting all the transports and starting over.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuart at tase

Mar 9, 2006, 8:21 AM

Post #5 of 6 (1775 views)
Permalink
Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk [In reply to]

On Thursday 09 March 2006 15:51, Daniel Kristjansson wrote:
> Is this only printed for transports where the MythTV scan does not
> insert any channels?

No, it's printed for every transport and we find channels for every transport.
It appears before the channels are inserted/updated.

> You should be able to scroll that window. The console message will provide
> a little more info, but it is basically telling you that there are some
> bogus dtv_multiplex entries and you should probably delete them and do a
> full scan to get less bogus ones.

Well I don't seem to have any keys bound that will allow horizontal scrolling.
Left/Right move to the next field/button. The entries in dtv_multiplex look
perfectly fine to me, but I've deleted them and will perform a full scan.

> This happens when it can't find any DVB/ATSC tables, but there are
> programs listed in the MPEG PAT table. This is used to detect the
> raw MPEG programs sent by most cable providers in the US. Have you
> tried tuning to one of these channels?

Nope, did think to. Will try that in a little while. Certainly there shouldn't
be any channels there ...

> This may be related to that "Found channel..." message you saw earlier,
> try deleting all the transports and starting over.

Trying that now.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuart at tase

Mar 9, 2006, 8:33 AM

Post #6 of 6 (1764 views)
Permalink
Re: [mythtv-commits] mythtv commit: r9305 - in trunk/mythtv/libs/libmythtv by danielk [In reply to]

On Thursday 09 March 2006 15:51, Daniel Kristjansson wrote:
> > I get a lot of bogus channels being added, all of which follow the same
> > pattern:
> > Adding C2#5 0-0 as 2#5 on Transport ID 8200 (0)
> > Adding C2#6 0-0 as 2#6 on Transport ID 8200 (0)
>
> This happens when it can't find any DVB/ATSC tables, but there are
> programs listed in the MPEG PAT table. This is used to detect the
> raw MPEG programs sent by most cable providers in the US. Have you
> tried tuning to one of these channels?

Again looking closer, at least some of these are not bogus. They have valid
service ids on the correct transports but are missing their callsign, channum
and name information. There is no valid reason for that information to be
missing so I'm guessing that's a bug.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

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