[mythtv] dvb scanning

[Stuart Auchterlonie]

On Thu, Jun 08, 2006 at 04:01:17PM -0400, Yeasah Pell wrote:
> Stuart Auchterlonie wrote:
> 
> >On Thu, Jun 08, 2006 at 02:05:37PM -0400, Yeasah Pell wrote:
> > 
> >
> >>Is anybody currently working on DVB scanning? It seems like it's in 
> >>rough shape generally, but there are some more obvious problems (such as 
> >>the fact that it doesn't change the DVB channel object's current input, 
> >>so the diseqc settings from the first input of that card are always used)
> >>   
> >>
> >
> >I have been looking at it scanning, but I don't have diseq hardware,
> >so any testing you do in this area would be helpful.
> > 
> >
> Good to hear it -- how's that going? I'd be glad to test any changes you 
> have at any time.
> 
> I have a few things that I'd love to get in there at some point:
> 
> 1) PAT/PMT-only scanning. This would scan just the basic mpeg tables 
> looking for programs, and add them as channels with generic names 
> (something like [mplexid-serviceid] perhaps) if it's a mplexid/serviceid 
> pair that hasn't been seen before. My cable provider literally transmits 
> nothing other than PATs and PMTs (well, except for the streams 
> themselves of course), as do some DVB-S channels (especially feeds) and 
> the only way I can get those in there is via external scanning or manual 
> entry, which is quite clunky.

That's already in there. If it doesn't get the other tables it should
insert channels from just that PAT & PMT

> 
> 2) Per source channel number offset. This would allow the user to set up 
> a per-videosource offset for channel numbers that are inserted into the 
> DB (i.e. channel numbers are set to the acquired serviceid plus the 
> offset, whether those serviceids came from importing, or various channel 
> scans) -- Right now I manually maintain various offsets for different 
> providers to avoid the confusion of channel number overlaps, but again 
> that's really clunky.

Not so sure about this one...

> 
> 3) This one's kind of out there, but ... optional background scanning. 
> You could set it up so that it would go and do transport scans during 
> idle time, similar to the active EIT scanner (more infrequently of 
> course, once a day or less), and it would automatically update stuff 
> based on those inputs you told it to rescan. This would be a big step 
> forward in DVB usability IMO, but it's definitely a much bigger task 
> than the other two ideas.

No, it's actually quite easy. We had this in v0.18 of myth, but in
some countries they don't maintain the placeholder for stations when
they are off air (say a 12hr per day station). So myth would see that
some of the channels "no longer existed" and dutifully remove it, then
the channel would come back later, and myth would add it back in.
Played absolute havoc with scheduling, so it was removed.

If it were to come back it would have to be in a form similar to how
my current STB does it, where it only marks channels as deleted without
removing them and puts in new channels with a 'new' marker next to them.

This is a bigger job....


Stuart

> 
> > 
> >
> >>Should I mess with the code at all, or just leave it alone because it's 
> >>being worked on?
> >>   
> >>
> >
> >Sounds like you've found a problem, feel free to create a patch for it.
> >If you do, attach it to ticket #1866
> >
> > 
> >
> I did fix it, but I'm going to make it part of the larger diseqc patch 
> I've got going, since otherwise I'd have to patch it for the old diseqc 
> code as well as the new stuff. It was a very minor change to siscan.cpp 
> (added an additional optional parameter to the DVB Tune() and 
> TuneMultiplex() methods to allow temporarily overriding the input), so 
> I'm not too worried about conflicts on that one.
> 
> /Yeasah