[mythtv-users] mythtv-setup DVB-T channel scanning problems (was: Re: should be local, but it can not be found)

Craig Sanders cas at taz.net.au
Tue Nov 30 22:47:29 UTC 2010


no idea if Brent's problem is the same as mine or not, but i found a
solution for the tuning & recording problems i've been having.

On Mon, Nov 29, 2010 at 11:34:36PM -0500, Greg wrote:
> On 11/29/2010 08:01 PM, Brent Bolin wrote:
> > Nagging problem in log files.
> >
> > Continue to see these errors -
> >
> > 2010-11-29 18:30:04.016 ProgramInfo(1321_20101129183000.mpg), Error:
> > GetPlaybackURL: '1321_20101129183000.mpg' should be local, but it can
> > not be found.
> > [..]
> >
> Any time I have had that happen to me,it was a failure of the
> capture device to start up...

there's more to it than capture card failure - i get the above errors
consistenly but ONLY on certain channels (all of the SBS channels incl
SBS ONE, SBS TWO, SBS HD, and all of the NINE channels 9, 99 GO, 90
GEM).  All other channels are fine.

(BTW my location is Melbourne, Australia - so all channels, frequencies,
networkids etc mentioned below are for that region)

this started on Sunday after i stopped all myth backends and ran
myth-setup on the master to scan for new channels. all channels used to
work before i scanned.

i've examined a diff of the channel table and noticed that there are
differences in some of the fields for several of the channels. e.g. for
SBS ONE:

fields:

(`chanid`, `channum`, `freqid`, `sourceid`, `callsign`, `name`, `icon`, `finetune`, `videofilters`, `xmltvid`, `recpriority`, `contrast`, `brightness`, `colour`, `hue`, `tvformat`, `visible`,
`outputfilters`, `useonairguide`, `mplexid`, `serviceid`, `tmoffset`, `atsc_major_chan`, `atsc_minor_chan`, `last_record`, `default_authority`, `commmethod`)

the data below has been edited slightly for readability - spaces add to
line up columns and the irrelevant icon field cleared to shorten the
line.

old data:

(1003,'3','',  1,'SBS ONE','SBS ONE','',0   ,'','sbsone.shepherd.au',3,32768,32768,32768,32768,'Default',1,'',1,6,785,0,0,0,'2010-11-25 00:05:01','',-1);

new data:

(1003,'3','29',1,'SBS ONE','SBS ONE','',NULL,'','sbsone.shepherd.au',0,32768,32768,32768,32768,''       ,1,'',1,11,785,0,0,0,'2010-11-30 00:15:01','',-1);

in particular, the freqid has changed from '' to '29', finetune has
changed from 0 to NULL, and the mplexid has changed from 6 to 11.

in two of the channels that still work fine (ABC1 & ABC2), the freqid
has changed from '' to 12 but the mplexid is unchanged (4 in both).

old:
(1021,'21',''  ,1,'ABC1','ABC1','',0   ,'','abc1.shepherd.au',3,32768,32768,32768,32768,'Default',1,'',1,4,563,0,0,0,'2010-11-24 23:28:01','',-1);
(1022,'22',''  ,1,'ABC2','ABC2','',0   ,'','abc2.shepherd.au',3,32768,32768,32768,32768,'Default',1,'',1,4,562,0,0,0,'2010-11-24 20:20:02','',-1);

new:
(1021,'21','12',1,'ABC1','ABC1','',NULL,'','abc1.shepherd.au',0,32768,32768,32768,32768,''       ,1,'',1,4,563,0,0,0,'0000-00-00 00:00:00','',-1);
(1022,'22','12',1,'ABC2','ABC2','',NULL,'','abc2.shepherd.au',0,32768,32768,32768,32768,''       ,1,'',1,4,562,0,0,0,'2010-11-29 21:54:01','',-1);


it looks like the mplexid has been renumbed along with the scan....so if
i compare the old and new records in the dtv_multiplex table, the old mplexid
6 looks very different to the new mplexid 11.

(`mplexid`, `sourceid`, `transportid`, `networkid`, `frequency`, `inversion`, `symbolrate`, `fec`, `polarity`, `modulation`, `bandwidth`, `lp_code_rate`, `transmission_mode`, `guard_interval`,
`visible`, `constellation`, `hierarchy`, `hp_code_rate`, `mod_sys`, `rolloff`, `sistandard`, `serviceversion`, `updatetimestamp`, `default_authority`)

old (no longer exists in the current mythconverg db):

(6, 1,784,12802,536625000,'a',NULL,NULL,NULL,NULL,'7','1/2','8','1/8',0,'qam_64','n','2/3','1',NULL,'dvb',1 ,'2009-11-17 21:50:44','');

new:
(11,1,864,12802,536500000,'a',NULL,NULL,NULL,NULL,'7','2/3','8','1/8',0,'qam_64','n','2/3','1',NULL,'dvb',33,'2008-08-06 07:52:38','');


searching the table for sourceid=784, there is another record that is almost identical to the old mplexid 6:

(16,7,784,12802,536625000,'a',NULL,NULL,NULL,NULL,'7','1/2','8','1/8',0,'qam_64','n','2/3','1',NULL,'dvb',3,'2009-04-10 11:25:41','');


if i run "update channel set mplexid=16 where chanid=1003;" in mysql
then I can now tune in to SBS ONE for both Live TV and Recordings.

similarly, "update channel set mplexid=16 where mplexid=11;" allows
me to watch & record ALL of the SBS channels:

mysql> select chanid,callsign,mplexid from channel where mplexid=16;
+--------+----------+---------+
| chanid | callsign | mplexid |
+--------+----------+---------+
|   1003 | SBS ONE  |      16 |
|   1032 | SBS TWO  |      16 |
|   1033 | SBS 3    |      16 |
|   1034 | SBS 4    |      16 |
|   1030 | SBS HD   |      16 |
+--------+----------+---------+

so, that tells me that there's something quite wrong with the scan
channels function in mythtv-setup. at a guess, it is choosing the first
mplexid for a given networkid so if the table has old data in it as well
as new (e.g. if the transportid or frequency or something changes) it
will choose the OLD data. maybe it should 'ORDER BY updatetimestamp DESC
LIMIT 1'



on an immediate practical level, it also tells me that if i find out
what the mplexid for the the NINE channels should be, i should be able
to fix it....

[10 mins later]

well, that didn't quite work for NINE. the dtv_multiplex table has two
entries for networkid=12829, and they're both exactly the same except
for updatetimestamp. and they're the same in the current table and in
the mysql backup data.

however, the backup data had another record in dtv_multiplex for
frequency=191625000 which was completely missing in the current table.
the only difference is that the networkid has changed from 12829 to
4114.

in old and new dtv_multiplex table:

(2 ,1,1072,12829,191625000,'a',NULL,NULL,NULL,NULL,'7','3/4','8','1/16',0,'qam_64','n','3/4','1',NULL,'dvb',24,'2009-04-10 09:06:40','');
(13,7,1072,12829,191625000,'a',NULL,NULL,NULL,NULL,'7','3/4','8','1/16',0,'qam_64','n','3/4','1',NULL,'dvb',24,'2009-04-10 11:24:31','');

only in old dtv_multiplex table:

(17,1,1072,4114 ,191625000,'a',NULL,NULL,NULL,NULL,'7','3/4','8','1/16',0,'qam_64','n','3/4','1',NULL,'dvb',24,'2009-11-17 21:50:29','');
 

which begs the questions - why did this record get deleted from the
dtv_multiplex table?  and why didn't the channel scan in mythtv-setup
pick up the networkid 4114?

anyway, "update dtv_multiplex set networkid=4114 where networkid=12829;"
fixes the NINE channels.  I can now watch and record channel 9, 90, and
99.


one final question is: is there a safe way of clearing *ALL* channel scan
data and forcing a complete scan from scratch?

is it as simple as 'delete from channel', 'delete from dtv_multiplex',
'delete from channelscan_dtv_multiplex' and then running mythtv-setup to
scan? or will that bugger up other things?

craig

-- 
craig sanders <cas at taz.net.au>


More information about the mythtv-users mailing list