[mythtv] dvb scanning

Yeasah Pell yeasah at schwide.com
Thu Jun 8 21:04:55 UTC 2006


>  
>  
>
>>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)
>>    
>>
>
>This wouldn't be of any use by me since my service ids are distributed 
>over the whole 2^16 space.
>  
>
Yikes, that sucks, but there isn't any 16-bit limitation on channel 
numbers (they are stored as varchar(10), so you have 5 more digits :-) ) 
So it could still work for you, but you'd end up with gigantic channel 
numbers (so probably not very practical, and may not work in the UI very 
well)

There's support in MythTV for ATSC-style channel numbering, right? (i.e. 
channel, subchannel with a separator) Perhaps a prefix would be a better 
way to go, so the channel ID would be some per-source configured prefix 
followed by the service id. How do you deal with overlaps right now?

Of course the desire for having non-overlapping channel numbers is only 
there because you can't set up arbitrary channel groups and operate on 
channel subsets via that grouping. Don't get me started on that :-)

>  
>
>>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),
>>    
>>
>
>This could be integrated into the EIT scan.  
>
>  
>
>>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.
>>    
>>
>
>It's IMHO not such a big task, all needed functions exists. It needs at 
>least a option to deactivate updates of existing channels (name, 
>callsign and number).
>For DVB-T and DVB-C it's not a big step in usability since the channel 
>listing are more or less static.
>  
>
Stuart just informed me that 0.18 actually used to have this feature, 
but it was removed because some channels didn't have stable presence and 
that was screwing with the scheduler as they came and went. I hope it 
wasn't removed completely, since that issue 1) sounds trivial to work 
around (i.e. disable deletes entirely, at least you have half of the 
benefit still), and 2) is not much harder to fix completely, either by 
waiting for the confirmation of several consecutive scans before 
deleting (you'd have to make sure it scanned often enough to actually be 
sure to catch the channel though -- maybe scheduling a scan of just the 
transport in question more often until the channel expires, and if it 
comes back you'd disable autodelete for that channel permanently), or by 
merely marking it as deletable for the user to go and purge manually. 
I'd certainly be up for working on that if the code is still around.



More information about the mythtv-dev mailing list