Sorting (un)available channels in lineup files.

[CraziFuzzy]

Minor issue, but for human readability, channel lists in the lineup files for available and unavailable channels should probably be sorted. I think it should probably be handled in ChannelLineup.getAllChannels(). A collection.sort with a custom compatator to sort by the first token(-) (primary channel number) and if equal by the second token (subchannel number).

Things like the offline scan running in a seemingly random order lead me to desiring this. I doubt getAllChannels is called often enough for the sort delay to matter.

[enternoescape]

One of the things I will be doing eventually is having the offline scan take more advantage of frequencies and checking the channels known to be within those frequencies because it's faster. If I get this in there, it will largely negate any sorting at least for CableCARD tuners, but adding a sort to this shouldn't really cause any meaningful performance issues.

[enternoescape]

I pushed some changes that will give you the desired effect. It's not the most efficient approach, but it handles the most common formats with the least amount of branching.

[CraziFuzzy]

Does the cablecard tuner even deal in frequencies at the level you are viewing it? I thought you only ever told it virtual channel numbers to tune. Especially with SDV, frequency is useless.

[enternoescape]

You are correct, but if we know the frequencies, and in many cases we do, changing virtual channels is faster within the same frequency than tuning into virtual channels that might be all over the place.

[CraziFuzzy]

Oh, okay, so it's more just an issue of staying where we're already tuned than it is about tuning initially. Still, I'm not sure how that information will be utilized practically - I mean, I guess during the offline scan, it will be of some use, as it'll sometimes get through the scan quicker, as long as the channels are still where they were last time.

And that speed is only if the HDHR doesn't release the tuner on a new tuner request - meaning if you are tuning from CH 104 (on freq X), and you tell it to change to CH 205, which also happens to be on freq X, does it keep the tuner locked and start grabbing new packets, or does it drop the tuner lock, lookup the frequency for the new channel, and then retune to the same frequency again? because the latter is not going to make things much quicker.

[CraziFuzzy]

I could see some advantage if, during a scan, say it tuned to the first channel in its list, and then during that scan, got the streaminfo for every channel on that frequency, and marked off all those programs, then went to the next unknown in the list, and did the same, until all were done - however, at least in my experimentation with hdhomerun_config.exe, the HDHR Prime doesn't provide complete streaminfo:

> hdhomerun_config.exe 13112BC2 set /tuner0/vchannel 768
> hdhomerun_config.exe 13112BC2 get /tuner0/streaminfo
831: 0 (encrypted)
874: 0 (encrypted)
876: 0
tsid=0x13D2

[enternoescape]

You're pretty much describing exactly why this hasn't been a high priority. I suspect it won't re-lock the frequency if it's already on it, but I haven't done enough testing on the HDHomeRun to know for certain if it's the case there. The InfiniTV devices tune faster to the same frequency even when you use a virtual channel, so it's likely they don't re-lock.

[enternoescape]

The channels are always sorted now.