[mythtv] Guide service API "Group By" usage

[Michael T. Dean]

On 09/28/2020 11:43 AM, Peter Bennett wrote:
> On 9/28/20 9:25 AM, Michael T. Dean wrote:
>>> On 9/25/20 2:56 PM, Peter Bennett wrote:
>>>>
>>>> The Guide API uses "Group by Callsign" with the result that if you 
>>>> have two channels with the same callsign, one gets dropped off the 
>>>> list. Is there any reason for this? I plan to fix it with the other 
>>>> bugs I am fixing, if nobody knows of a reason for grouping that way.
>>>>
...
...
>> In theory, the guide should only condense multiple channels to a 
>> single listing if both the call sign and channel number are identical 
>> for the channels.  If you're saying that's not the case in the 
>> services API or something (it condenses if the call sign is identical 
>> regardless of the channel number), that may be a bug.
>>
> Yes that is what the services API does for the GetProgramGuide (Group 
> by call sign and not channel number). My particular case was where two 
> channels have the same call sign but different numbers and only one 
> showed.

Yeah, TTBOMK, we still show multiple rows if either call sign or channel 
number differs in the frontend guide and should in all other guides 
(MythWeb and/or backend services).  I don't have duplicate channels, so 
it's possible things have been changed in recent years and I didn't 
notice, but it seems to be a bug to me.  With the distinctions between 
identical channel numbers, identical call signs, and identical channel 
numbers and call signs I described in my previous message, we seem to 
cover cases that allow users fine-grained control over "what kind of 
duplicate channel is this," so I wouldn't expect we should remove some 
portion of that control. I'd think the service should be changed to 
condense channels like the frontend channel guide.

> Here in the USA with cable we prefer channel number, the callsigns 
> filled in by the guide service are not consistent. Many times they are 
> some sort of abbreviation of the channel name, sometimes with -DT, 
> -DT2, -DT3 etc. appended.
>
> I recently came across somebody (I don't know where located) who has 
> null channel numbers. I did not think that was allowed but it may mess 
> up grouping by channel number.

Yeah, though it shouldn't have an effect on scheduling, it would almost 
definitely have negative effects elsewhere (such as Live TV's inability 
to tune by channel number, display problems, or in transmitting 
ProgramInfo using Myth backend protocol--because of null-terminated 
strings).

> I am not sure if SQL will correctly group items that have null in 
> their group by column.
>
> Should null channel numbers be allowed?

The column is defined as NOT NULL:

https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/dbcheck.cpp#L3894

and I don't see any changes anywhere that removed that restriction (nor 
can I imagine changes that would do that).  Not sure what the preferred 
approach is regarding coding to handle that invalid data transparently 
or requiring valid data, but we probably should at least alert the user 
that their DB (and, seemingly DB schema) is borked if we notice 
that--whether we fail hard or "just try and see" or insert some value in 
code when reading null from the DB column to try to prevent errors.  My 
personal preference is to not spend a lot of time coding to handle 
invalid data, but to log a message that makes it possible for the user 
to figure out what's wrong and correct it.  That said, I'm not at all 
against bulletproof (or bullet-resistant?) code.  (So, I guess that's 
completely useless advice, and maybe someone else can be more helpful. :)

Mike