[mythtv-users] Rigging Channel Lineup
R. G. Newbury
newbury at mandamus.org
Sun Aug 12 22:05:14 UTC 2007
Daniel Kristjansson wrote:
> On Fri, 2007-08-10 at 21:49 -0400, R. G. Newbury wrote:
>> I have a mix of analog cable and OTA digital channels. The OTA channels
>> show up in order of the actual channel frequency and changing channum
>> (from 7.1 to 107.1) does not change the order.
> They are ordered by ATSC major and minor, when the channum is of the
> form 7.1,7-1,7_1,71, but ordered by channum as a number if channum
> is an integer other than "71" in the case of 7-1, so long as all the
> other integer sorting can work with all the non-ATSC channels in your
> channel list. The reason 107.1 fails to get reordered is because
> it is neither a straight remapping of the ATSC channel nor an
> integer channel. channelutil.cpp's lt_smart() is using a fall-back
> which retains a deterministic ordering, I would guess it's ordering
> by the ATSC major and minor.
>> I understood that digital channels do not use the freqid, but instead
>> use the tuning information referenced through mplexid into the dtv
>> _multiplex table. But that seems to make atsc_major_chan, and
>> atsc_minor_chan redundant along with freqid.
>> Clearly, analog channels need only the freqid. But do digital channels
>> use that field at all? Can I arbitrarily change that field?
> The frequency in the dtv_multiplex table is used whenever a
> dtv_multiplex row is referenced by a channel row, whether the
> channel is digital or not. A pcHDTV card can work without the
> dtv_multiplex table when using the old V4L drivers, but MythTV
> doesn't insert these types of channels in the channel scanner.
> The atsc_major_chan and atsc_minor_chan are not redundant at
> all, none of the channels in NYC are on the major channel the
> frequency in dtv_multiplex would indicate, but the ATSC major
> and minor are still needed to pick out the sub-channel to tune
> to. (Maybe things are a lot more orderly in Canada?)
>> I tried to read the code, but got lost. Very quickly I might add. I was
>> unable to even find where the mysql select statement for the EPG is...
> Look at GuideGrid::fillChannelInfos() this pulls in the
> channels, then look at ChannelUtil::GetChannels() and
> ChannelUtil::SortChannels(channels, channelOrdering, true)
> these two are the real meat of what is going on. GetChannels gets
> all the channels grouped by channum and callsign. Then
> SortChannels sorts them by the configured "ChannelOrdering",
> by default this is "channum", but this can be configured to
> sort by "callsign". While the default ordering is called
> "channum" this is only for backward compatibility in the db,
> this is really what was called "smart" ordering during
> development. The whole "smart" algorithm for ordering is
> described by channelutil.cpp's lt_smart() function.
Thanks, that helps. Although I thought that the sub-channel was being
referenced by 'serviceid' in the channel table.
And the problem is that it is not 'more orderly' in Canada. In fact,
that is the problem. None of the digital channels in the Greater
Toronto/Golden Horseshoe area (except for Buffalo PBS (WNED) 3 channels)
are 'called' by a channel.subchannel name which matches the tuning
channel they are actually on...For example CBLTDT 5.1 (the digital
version of CBLT analog channel 5) is broadcast on real channel 20.
I suspect that this will be problem for a couple of years, until we
become comfortable with the new channel naming conventions.
I know that making schema changes is not encouraged, but given the
upcoming SchedulesDirect changes, maybe adding an ordering field to the
channel table would be useful...An arbitrary (float) value. It is clear
that 'channum'/ lt_smart does not work as implied by the
More information about the mythtv-users