atscsrcid can't handle minor channels > 255

[danielk]

This is not a problem with OTA ATSC, but now that some Cable providers have begun to transmit ATSC info some are using very large minor channel numbers.

[danielk]

Fixes the atscsrcid problem (lightly tested).

[danielk]

Version that only changes the channel sorting

[danielk]

(In [10376]) Refs #1966. Changes channel sorting to be a bit smarter.

Instead of sorting on the fly using the database ChannelUtil::GetNextChannel?(), this adds two methods GetChannels?() and SortChannels?() to create a sorted list of channels, and changes GetNextChannel?() to take this sorted list.

This means we don't need a DB query for this and it means that we can use more sophisticated sorting methods. The reason I wrote this was because the atscsrcid removal removes the only reasonable DB sort method for channels. This repurposes "channum" sorting to be the new smart channum sorting which first compares major channels then minor channels, then compares the channum's numerically if possible, and then compares the channum's as strings, and finally if this fails compares the callsigns. If any of these differ the channels will be ordered uniquely and in a sensical manner. This new channum order supercedes all the ordering methods except callsign ordering which remains the same.

This works well for me, but I need some people in other countries to test this; I have a valid atscsrcid, for both ATSC and NTSC sources, I'm not sure if that is the case for everyone.

There are also a couple cases I would like someone familiar with the scheduling and schedule viewing to look at. In ProgramList::FromProgram?() the ordering was by whatever channel ordering was set to, I changed this to chanid. Does this need to be ordered exactly like the channels are? Also In ProgramList::FromRecorded?() I used a better approximation to the new smart ordering that the database can handle, same question here, is this approximation sufficient? The first is probably more important since I can't sort them exactly the same way without expanding the "LIMIT 1000".

[danielk]

(In [10383]) Refs #1966. Uses common ChannelUtil? functions GetChannelData?() and GetTuningParams?() for the DVBChannel, HDHRChannel and Channel SetChannelByString?() method.

This also replaces GetATSCSRCID() with GetATSCChannel() and adds a IsATSCChannel() function to ChannelUtil?.

Finally, this adds a fallback tuning to TVRec::InitChannel?() so that if the DB somehow has an invalid startchannel, we'll be sure to tune to a valid channel if there are any connected inputs with channels.

[danielk]

(In [10389]) Refs #1966. Converts the channel table's atscsrcid column into two columns, one for each component of the channel.

This changeset adds two columns atsc_major_chan and atsc_minor_chan which replace atscsrcid. The new columns are populated with the data from atscsrcid so there is no need to rescan if things were working for you before.

The old column was not only a misnomer, since there is such a thing as an ATSC source id (this rarely implemented properly in practice, so we don't store it in the DB), but also could not handle some of the newer cable encodings which use the ATSC minor channel to enumerate their cable system channel numbers, up into the 1000's.

[danielk]

(In [10391]) Refs #1966. Makes ProgramList::FromProgram?() order the same way as other DB channel orderings.

See log on [10376] for more info, but basically I discovered where the ordering actually mattered, i.e. in ProgFinder::selectShowData(), all the other places restrict the query so that only one channel is returned.

I also looked at the places where FromProgram?() and FromRecorded?() were being used, and removed the "DESC" keyword from the callsign portion of the channel ordering in these. It looks like it was only the starttime that we wanted to possibly be descending. In these places this is used, having the channel order reversed doesn't make much sense.

[danielk]

(In [10392]) Closes #1966. Merges mythtv-atscsrcid to head.

This splits the atscsrcid column into two columns atsc_major_chan and atsc_minor_chan to support ATSC channels in QAM which uses much larger numbers for minor channels.

This introduces a smart channel sorting method that can handle mixed system channel lineups much better. i.e. DVB-S + ATSC + NTSC channel are sorted inteligently when they are in the same lineup.

This adds code to TVRec::InitChannel?() to fall back to a channel in your lineup when your startchannel does not exist in the lineup and so is not tunable. This assures that LiveTV is not broken when a channel disappears from your lineup, or the user forgets to set it after the initial mythfilldatabase run.

These changes are explained in more detail in the mythtv-atscsrcid commit logs attached to Ticket #1966. I've been running a version of this for about two weeks without serious problems (only sorting problems which have been fixed), but I'll be on the lookout for any error reports in the coming week.

[danielk]

(In [10404]) Refs #1966. Smarter smart channum ordering.

This will handle renumbered channels, and will only use the ATSC comparison if one of the two channels being compared is an ATSC channel.

[danielk]

(In [10405]) Refs #1966. Deals gracefully with lineups with a bogus mplexid we used to insert.

I would just to a DB fix, but I'm not sure the problem has been completely excised.

[danielk]

(In [10406]) Refs #1966. Fixes DB update 1150 wrt MySQL 3.23.

This just breaks up the atsc_major_chan and atsc_minor_chan updates into two smaller queries which older MySQL DBs can handle without spitting out an "Unknown Error" when the atscsrcid column is NULL.

[danielk]

(In [10455]) Refs #1966. Removes "group by callsign" on the program guide query, and uses the sort function to eliminates duplicates.

This means only exact duplicates are removed when using the "channum" sorting method, and the bahaviour is basically unchanged with the "callsign" sorting method.

[danielk]

(In [10465]) Refs #1966. Refs #2041. Fix channel flipping when not in browse mode.

The channel flipping code depended on GetNextChannel?() looking up the current channel when no channel was provided. The new implementation of GetNextChannel?() was not checking for this condition so it always fellback to changing channels with respect to the first channel in the lineup.

[danielk]

(In [10469]) Refs #1966. Refs #2033. Applies the atsc_major_chan,atsc_minor_chan part of the siscan patch on #2033. This should allow DVB-T/DVB-C channel insertions to work again.

[danielk]

(In [10471]) Refs #1966. If an ATSC channel has been radically renumbered, use the channum value for sorting.

For example,

These are sorted as ATSC channels:

major 4 minor 11 with channum "4_11" major 41 minor 1 with channum "41.1"

These are sorted by channum:

major 10 minor 1 with channum "910" major 10 minor 2 with channum "911" major 4 minor 1 with channum "913"

[danielk]

(In [10475]) Refs #1966. Fixes #2032. Fix insertion of pure MPEG channels when ATSC and DVB scanning fails.

[anonymous]

Replying to danielk:

(In [10471]) Refs #1966. If an ATSC channel has been radically renumbered, use the channum value for sorting.

I'm using 0.20-fixes, which incorporates this patch. Apologies for reopening the ticket, but would it be possible to extend this patch so that it sorts by channum even if the ATSC channel hasn't been "radically renumbered"?

In my setup, I don't use any separators (like _, #, or .) in the channel numbers for ATSC channels. As a result, 2.1 appears as 21, 11.1 appears as 111, etc. I do this because channel numbers ought to be just numbers with no newfangled punctuation symbols, gosh darn it.

However, this means that in places like the Program Guide, MythWeb's channel listings, and Schedule Programs|Search Lists|Channels, the channels don't get sorted by strict numerical channel order; 21 appears after 2 and before 3, for example. I know why this is the case, and would probably welcome such behavior were I using a separator, but this is precisely why I don't want to use a separator in the first place.

[ylee@…]

Sorry, forgot to actually reopen the ticket.

[Janne Grunau]

please don't reopen old tickets for new feature requests. And don't open a new ticket for a feature request.

I do not think that sorting channel numbers alphabetically even if the are numbers justifies another option let alone changing the default behaviour.

Please use a channel seperator or live with the current behaviour.