Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 8 years ago

Closed 7 years ago

#1966 closed task (fixed)

atscsrcid can't handle minor channels > 255

Reported by: danielk Owned by: danielk
Priority: minor Milestone: 0.20
Component: mythtv Version: head
Severity: medium Keywords: atsc channel sort number separator
Cc: Ticket locked: no

Description

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.

Attachments (2)

1966.patch (101.9 KB) - added by danielk 8 years ago.
Fixes the atscsrcid problem (lightly tested).
1966-sort-only.patch (48.1 KB) - added by danielk 8 years ago.
Version that only changes the channel sorting

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by danielk

Fixes the atscsrcid problem (lightly tested).

Changed 8 years ago by danielk

Version that only changes the channel sorting

comment:1 Changed 8 years ago by 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".

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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.

comment:5 Changed 8 years ago by danielk

  • Resolution set to fixed
  • Status changed from new to closed

(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.

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by 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.

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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.

comment:12 follow-up: Changed 8 years ago by 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"

comment:13 Changed 8 years ago by danielk

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

comment:14 in reply to: ↑ 12 Changed 7 years ago by 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.

comment:15 Changed 7 years ago by ylee@…

  • Keywords atsc channel sort number separator added
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Summary changed from atscsrcid can't handle minor channels > 255 to Sort ATSC channels by strict numerical order if no separator is used

Sorry, forgot to actually reopen the ticket.

comment:16 Changed 7 years ago by janne

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Summary changed from Sort ATSC channels by strict numerical order if no separator is used to atscsrcid can't handle minor channels > 255

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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.