Channel number sorting/collating

Channels DVR Server
#1

I've noticed some discrepancies with how channel numbers are sorted within Channels depending upon the platform. While I'm sure this is an edge case, I think it might occur more often than is realized. Also, this is only noticed when one uses different numbering schemes—whole numbers for cable channels, decimal numbers for OTA broadcast channels, some other format for Custom Channels.

While setting up a Channels instance for my parents, I used Custom Channels to mimic their existing DirecTV lineup. For sub-/alternate channels, DirecTV uses dash (“-”) notation. For example: TNT (Eastern/national) is 245, but the Pacific feed is 245-1; NESN is 628, NESN+ is 628-1. When checking the lineups in the iOS/iPadOS apps, the channels were sorted as one would expect: 245, 245-1, 628, 628-1. However, both the Android app and the DVR's web UI sorted the alternate channels first: 245-1, 628-1, 245, 628.

Likewise, the sorting for dot (“.”) notation channels differs between Apple clients and both the Android clients and web UI. One would expect the integer number (3) to be sorted before any sub-channels (3.2); this is how it is sorted on the Apple clients. However, the opposite is true for Android/web UI. Extending the metaphor for DirecTV numbering: local OTA broadcasts of NBC include 2 channels: 4.1 NBC, and 4.2 Cozi TV; the DirecTV numbering just has NBC on 4. To incorporate a cable/TVE feed in the lineup with OTA numbers, one would then expect: 4, 4.1, 4.2 (which is what happens with Apple clients). But, Android clients and the web UI show lineup as: 4.1, 4.2, 4.

Is there a different Unicode/collation library being used between platforms (Apple/Android/server)? Does the server's collation come from the host system, or does it use Golang's string libraries? Is there something else that might account for the different sorting between platforms?

I know this is an edge-case, and not really a showstopper of a bug. But it certainly is a papercut, and does make consistency between platforms problematic. (In my situation, to alleviate confusion I simply reduced all channel numbers to whole integers, and reassigned sub-/alternate channels to other numbers. While that worked in my case, it is a bandaid, and not a genuine solution.)

#2

Just to confirm: this behavior is seen on the android Guide, when the app is set to Lineup Order: Channel Number?

#3

I may have to set up a new test case to verify, but I believe so. However, it may have also been set to "Default". (Which doesn't really sound very descriptive: what is the "Default" lineup order? Is that the way it was retrieved from the source? By number? Some other metric?)

#4

Default and Number are the same. It was intended that Default would change in the future once the server could have a custom order defined.

To sort we split the number on the "." and then sort by the numeric parts individually. I'm not sure why it's not working as intended on Android.

How about on the web UI, was that on the Guide tab as well?

#5

Here are some examples:

I created a brief playlist with the following lineup:

  • 100 INT
  • 100-1 DASH1
  • 100-2 DASH2
  • 100.1 DOT1
  • 100.2 DOT2

Logically, that is how I would expect the channels to be sorted. However, that is not the result I get.

DVR:

web1
web1721×490 42 KB

web2

Android:

image
image4032×3024 3.71 MB

image
image2016×1512 1.39 MB

Apple:

image
image828×1792 306 KB

Source playlist:

#EXTM3U
#EXTINF:-1 channel-id="test-int" channel-number="100",INT
http://localhost/test.ts
#EXTINF:-1 channel-id="test-dash1" channel-number="100-1",DASH1
http://localhost/test.ts
#EXTINF:-1 channel-id="test-dash2" channel-number="100-2",DASH2
http://localhost/test.ts
#EXTINF:-1 channel-id="test-dot1" channel-number="100.1",DOT1
http://localhost/test.ts
#EXTINF:-1 channel-id="test-dot2" channel-number="100.2",DOT2
http://localhost/test.ts
1 Like
#6

Dashed numbers are not something we ever saw coming from HDHR, so it's not currently supported.

The bug on Android where dotted and non-dotted channels were sorted incorrectly is fixed in the next beta.

#7

Thanks, Aman. Understandable about dash-notation for channels. Coming from Tvheadend, dash and dot were treated interchangeably; also, many TVs seem to prefer dash-notation for sub-channels.

With Android sorting fixed, the channel scheme can be changed to all dot-notation.