[mythtv] Guide service API "Group By" usage
Michael T. Dean
mtdean at thirdcontact.com
Mon Sep 28 17:28:22 UTC 2020
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
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
> 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:
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. :)
More information about the mythtv-dev