[mythtv-users] HD Homerun Prime Scripting

[Mike Perkins]

On 19/10/11 14:37, Eric Sharkey wrote:
> On Wed, Oct 19, 2011 at 6:11 AM, Mike Perkins
> <mikep at randomtraveller.org.uk>  wrote:
>> On 18/10/11 21:07, Eric Sharkey wrote:
>>> On Tue, Oct 18, 2011 at 11:48 AM, Kirk Bocek<t004 at kbocek.com>    wrote:
>>>
>>> I still feel that it would be best to have a single video source for
>>> both prime and non-prime tuners, but, since the devs seem to have no
>>> aesthetic problems with the current proliferation of video sources,
>>> we're pretty much stuck with having to maintain the non-prime source
>>> based on external information.
>>>
>> A 'source' defines the channels available to a single method of tuning, plus the
>> means of tuning them. Therefore, you /cannot/ use the same source for both prime
>> and non-prime channels, since by definition the lists of channels available will
>> be different. (If they are not, why are you bothering?)
>
> That's the current mythtv design, yes.  I'm critiquing that design and
> expressing that I fundamentally disagree with design decisions for the
> mythtv database schema.
>
> The problem, as I see it, is that the database has lots of duplicate
> information and fails to measure up to a single source of truth
> design:
>
> http://en.wikipedia.org/wiki/Single_Source_of_Truth
>
> When Comcast sends me a channel, they send it once.  It has one
> frequency, one call sign, one xmltvid, one virtual channel number,
> etc.  Why do I need to have this channel information duplicated in the
> database?  It's important that this channel have the same call sign in
> all of its entries but the call sign is usually slightly different
> when doing a clear qam scan vs. downloading the list from schedules
> direct and it's up to the end user to sort this out.  Why is that?
>
> You could separate this out by splitting the channel table in two.
> Have chanid, callsign, xmltvid, virtual channel number, etc. in one
> table, and make the video sources table be just the sourceid, chanid,
> and tuning information for that that channel on that source.  That
> would simplify maintenance of the qam channel list considerably.
>
I thought that was the difference between the 'channel' table and the 
'dtv_multiplex' tables.

Don't forget, the ways of tuning a single 'channel' of content are many and 
various. All that you describe is meaningless (well, almost) to us on the other 
side of the pond.

When such is the case, the devs have to make compromise choices between the data 
required to tune each channel and the methods chosen by each provider.

I certainly agree that the information should be stored only once in the 
database, and for the UK that is what happens. We have multiplexes (frequencies) 
and each contains a number of channels, each mapped to that multiplex. It would 
be possible for me to receive multiplexes from more than one transmitter, and in 
those cases there would be duplicate channel records (ie providing the same 
programming) (Mostly). To remove those would require a channel/multiplex link 
table, with information that would be useful to only a small number of users but 
at a much greater complexity in coding for everyone. Do you really want that?

-- 

Mike Perkins