[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