Sort Order by channel number EPG

fixy3

Hi there.

How is it possible to sort by Number ASC/DESC in EPG View?
When i sort ASC, there is
... -> 3353 -> 3354 -> 1 -> 3-> 5 -> 9 -> ... ->3265 -> 3269 -> 2 -> 4-> 6 -> 7 -> 8 -> ...

I know, there are high Channel Numbers, but there are "doubled" an SD, on higher Numbers for some reasons.

Greetings 🙂

DeltaMikeCharlie

fixy3 How is it possible to sort by Number ASC/DESC in EPG View?

You have found a bug. Congratulations. 🥳

The problem has been identified and a fix is in progress.

DeltaMikeCharlie

I see the same thing on my system when I sort ASC on channel number.

It only happens for 4 digit numbers. If I set the channel number to be 3 digits, it sorts normally.

This may need some more investigation.

Chris G

Can confirm.
Only ever sort alphabetically, so I never noticed this.

DeltaMikeCharlie

I think that I have found the issue here: tvheadend/tvheadendblob/fa8011b4667df787c4d6c6acfa443dd68d0f13ea/src/epg.c#L2612C1-L2617C2

static int _epg_sort_channel_num_ascending ( const void *a, const void *b, void *eq )
{
  int64_t v1 = channel_get_number((*(epg_broadcast_t**)a)->channel);
  int64_t v2 = channel_get_number((*(epg_broadcast_t**)b)->channel);
  return v1 - v2;
}

This is the sort comparison function that returns a (signed) int to indicate how qsort should process these 2 elements. However, the channel numbers are always stored as int64_t multiplied by 1000000. So, channel '3333' is stored as '3333000000' in the int64_t. This is all fine until the result of v1 - v2 is greater than 2³¹ (2,147,483,648) when an overflow occurs and the qsort function fails. This also explains why channel '333' is OK.

The function _epg_sort_channel_descending will also misbehave due to the same issue.

DaveH

DeltaMikeCharlie However, the channel numbers are always stored as int64_t multiplied by 1000000.

The obvious question is "why?" What benefit is gained by the multiplication?

That's ignoring the other question, which is "why use four-digit channel numbers?" But I expect there's a reason for that.

davep

DaveH The obvious question is "why?" What benefit is gained by the multiplication?

ATSC uses Logical Channel Numbers with a decimal point eg 35.11, so multiplying the number before converting to integer makes sorting work. Choosing to multiply by 1000000 seems a little excessive though.

That's ignoring the other question, which is "why use four-digit channel numbers?" But I expect there's a reason for that.

Sky on Astra 2 use four-digit LCNs for radio channels.

DeltaMikeCharlie

davep ATSC uses Logical Channel Numbers with a decimal point eg 35.11, so multiplying the number before converting to integer makes sorting work.

It would seem that your ATSC hypothesis is correct.
tvheadend/tvheadendc073538