Channel Group per Video Source for Program Guide

[kmdewaal]

The Program Guide in mythfrontend shows all channels of all video sources that are connected to capture cards. In a MythTV system with multiple video sources the number of channels can become very big. Each video source has its own channel numbering, either from LCN (logical channel numbers), major/minor or service IDs. The Program Guide shows all channels combined sorted on channel number; this means that the channels from all video sources are all mixed up.

A way to deal with this is to add a selection mechanism so that the Program Guide can be instructed to show the channels of only one video source.

There is the Channel Group feature that allows the user to create a collection of channels that is then shown in the Program Guide instead of the full list of channels. This mechanism can be used to create a channel group for each video source. I have made a prototype implementation that does this now automatically at the start of the backend.

The current prototype works like this:

• A channel group is created for each video source that is connected to a capture card.
• The channel group has the same name as the video source.
• All visible channels of the video source are added to the channel group. This is done at the start of mythbackend. Over time the list of channels will change; therefore the following is also done at startup:
• Remove all channels and then add all visible channels. Over time a video source can become unconnected; therefore the following is also done at startup:
• Remove all channels and the channel group when a video source is not connected.

For the presentation, the list of channel groups is ordered so that first the manually created channel groups are shown and then the channel groups for the video sources.

It is the expectation that the functionality as described above is good enough but corner cases can be identified. It will go wrong in the following circumstances:

• When there is a manually created channel group with the same name as a video source However, this is something that can be easily avoided by the user. Another potential issue is the deletion of a video source in mythtv-setup; this will then leave a channel group corresponding to that video source. This can be solved by letting mythtv-setup also delete the channel group when it is deleting a video source, but this it not yet in the prototype implementation. It is of course already possible for the user to delete a channel group manually.

It is possible to address the corner cases and make this really foolproof but that requires adding a field to the channelgroupnames table in which it can be marked that a channelgroup represents a video source.

This is a screenshot of the Channel Group selection window: The group "All Channels" is hard-coded and appears always on top. The group "Favorites" is always present in the database but has to be maintained manually. The group "Sports" is manually added. The following four groups correspond to video sources.

The code with the prototype implementation will be attached.

The plan is to put this in master one of these days.

[kmdewaal]

20220728-videosourcechannelgroup.patch.gz

[gigem]

On Thu, Jul 28, 2022 at 10:17:05AM -0700, kmdewaal wrote:

The Program Guide in mythfrontend shows all channels of all video sources that are connected to capture cards. In a MythTV system with multiple video sources the number of channels can become very big. Each video source has its own channel numbering, either from LCN (logical channel numbers), major/minor or service IDs. The Program Guide shows all channels combined sorted on channel number; this means that the channels from all video sources are all mixed up.

A way to deal with this is to add a selection mechanism so that the Program Guide can be instructed to show the channels of only one video source.

There is the Channel Group feature that allows the user to create a collection of channels that is then shown in the Program Guide instead of the full list of channels. This mechanism can be used to create a channel group for each video source. I have made a prototype implementation that does this now automatically at the start of the backend.

The current prototype works like this:

• A channel group is created for each video source that is connected to a capture card.
• The channel group has the same name as the video source.
• All visible channels of the video source are added to the channel group. This is done at the start of mythbackend. Over time the list of channels will change; therefore the following is also done at startup:
• Remove all channels and then add all visible channels. Over time a video source can become unconnected; therefore the following is also done at startup:
• Remove all channels and the channel group when a video source is not connected.

For the presentation, the list of channel groups is ordered so that first the manually created channel groups are shown and then the channel groups for the video sources.

It is the expectation that the functionality as described above is good enough but corner cases can be identified. It will go wrong in the following circumstances:

• When there is a manually created channel group with the same name as a video source However, this is something that can be easily avoided by the user. Another potential issue is the deletion of a video source in mythtv-setup; this will then leave a channel group corresponding to that video source. This can be solved by letting mythtv-setup also delete the channel group when it is deleting a video source, but this it not yet in the prototype implementation. It is of course already possible for the user to delete a channel group manually.

It is possible to address the corner cases and make this really foolproof but that requires adding a field to the channelgroupnames table in which it can be marked that a channelgroup represents a video source.

This is a screenshot of the Channel Group selection window: The group "All Channels" is hard-coded and appears always on top. The group "Favorites" is always present in the database but has to be maintained manually. The group "Sports" is manually added. The following four groups correspond to video sources.

The code with the prototype implementation will be attached.

The plan is to put this in master one of these days.

In general, I like this, especially if it can be extended to handle a pet issue I have. Here are a few comments and a request in no particular order.

I've toyed with the idea of mostly doing away with channel numbers and only displaying callsigns. The current default is to collapse channels that have the same channel number and callsign into a single channel in the EPG and elsewhere. This change would optinally collapse channels using only callsign.

There is a scheduling filter called "Priority channels" which only matches channels where channel.recpriority > 0. I use this by default to exclude most SD and some other channels. If I ever really do want to record from one of those channels, I turn off the filter for that specific recording rule. Note that this is not the same as marking a channel invisible. In order record from invisible channels, the channel needs to be changed to visible which means it could then be considered for use with all recording rules. Long story short, I'd like to see an option to your automatic, channel groups to include a Priority Channels group and only include priority channels in the videosource groups.

I doubt setting up the automatic groups would take much time but doing it at every backend startup doesn't seem right. What about only doing it when the videosources or channel priorities change?

Another change I think I'd like to see is honoring the current channel group in other places besided the EPG. For example, all of the other ways under Schedule Records that browse guide data always show all channels. I'd probably like them to limit the view to the current channel group by default and allow the user to change the group when desired.

David -- David Engel @.***

[paul-h]

I've toyed with the idea of mostly doing away with channel numbers and only displaying callsigns.

In the UK and probably most of the world outside the US channel numbers are the normal way to identify a channel. Callsigns are completely alien to us and something we never use.

[gigem]

Paul, we've had this discussion before. Too many time before. Short answer, I speciically said optionally, although I didn't spell it correctly.

Longer answer, you do have callsigns even if they're only under the hood. Question: when you suggest a program to a friend, do you tell them it's on BBC1 or channel 43?

As Klaas noted, some people have multiple videosources with lotts of channels. I have 3 with lots of duplicated channels. At some point, forgetting the numbers and referring to them by name/callsign makes more sense.

Finally, I don't know how popular streaming services are in the UK but they're gaining popularity over here. Many, maybe even most of them, including YouTube TV, don't have channel numbers at all. Users are expected to navigate between channels solely using the EPG.

[garybuhrmaster]

.... At some point, forgetting the numbers and referring to them by name/callsign makes more sense.

Probably for most people, although I just remember the numbers if I care about channels (I have been told I am not considered normal, but then again most MythTV users are not considered normal (being in the less than 1% club) so I consider myself in somewhat friendly non-normal company). Mostly I don't care about channel numbers, I care about content. The channel is just the way to get there in the classic world.

Finally, I don't know how popular streaming services are in the UK but they're gaining popularity over here. Many, maybe even most of them, including YouTube TV, don't have channel numbers at all.

Although (for "reasons"?), some (many?) guide providers assign channel numbers for the OTTs that are offering (sort of classic) "Live TV" service equivalents such as YTTV (not so the pure streaming services such as Netflix). I can send you a list of the channel numbers that Schedules Direct uses with YTTV if you like, although since no one watches things live, they just record for future consumption, those channel numbers are mostly not useful anyway except for source context.

Users are expected to navigate between channels solely using the EPG.

I believe even for more and more classic TV providers you are expected to talk (yell?(*)) at your TV, saying "Show me Parks and Recreation" (at least that is what the ad on my local cable provider that Amy Poehler is in says to watch one of her favorite shows).

There are, of course, some people who still want a classic EPG. They are, as you say, going to become more and more disappointed as everything (other than event TV (sports and breaking news)) moves to various forms of on-demand viewing.

(*) I am old enough to remember the parents having a verbal manual remote control, yelling at the kids to change the channel, or turn up the volume.

[paul-h]

I do think you are assuming that what is the norm in the US is the same the world over and it is not. All the popular DVR's in the UK that I have used like those from Freeview, Freesat, Sky and Virgin still use channel numbers and names. If you want to go to BBC1 on most DVRs it is channel number 101 so that is what you enter to change channel. Most users know the channel numbers of the popular channels they use. We have never used or heard of callsigns until we started to use MythTV.

Even Pluto TV uses channel numbers, so does the Samsung Plus EPG on my TV and I think Freview Play does. They are just the norm here so it would be very bad for MythTV users outside of the US to remove them IMHO. I know my opinion doesn't count for much round here but it is my honest opinion.

If it is optional then that is fine :)

[gigem]

On Thu, Jul 28, 2022 at 04:35:16PM -0700, Gary Buhrmaster wrote:

Although (for "reasons"?), some (many?) guide providers assign channel numbers for the OTTs that are offering (sort of classic) "Live TV" service equivalents such as YTTV (not so the pure streaming services such as Netflix). I can send you a list of the channel numbers that Schedules Direct uses with YTTV if you like, although since no one watches things live, they just record for future consumption, those channel numbers are mostly not useful anyway except for source context.

Is that just for local channels or all channels. I ask because I was directly told just this week by a trusted source that YTTV doesn't use channel nubmers.

(*) I am old enough to remember the parents having a verbal manual remote control, yelling at the kids to change the channel, or turn up the volume.

Ah, come on. I thought you were old enough to remember the most important adjustment -- fixing the horizontal role!

David -- David Engel @.***

[gigem]

On Thu, Jul 28, 2022 at 04:35:35PM -0700, Paul Harrison wrote:

I do think you are assuming that what is the norm in the US is the same the world over and it is not. All the popular DVR's in the UK that I have used like those from Freeview, Freesat, Sky and Virgin still use channel numbers and names. If you want to go to BBC1 on most DVRs it is channel number 101 so that is what you enter to change channel. Most users know the channel numbers of the popular channels they use. We have never used or heard of callsigns until we started to use MythTV.

No, the only assumption I made, and rightly so, was that you would quickly jump in to resurrect this old, tired point. :)

If it is optional then that is fine :)

It's MythTV. Almost everything is optional.

I do think you're too focused on the EPG use case, though. Do you ever use the other, showings feature or other, guide, search screens? If you do and see 3, 4 or even more entries for every showing because the same channel has multiple numbers, you might start to think differently.

David -- David Engel @.***

[jpoet]

On Thu, Jul 28, 2022 at 7:55 PM David Engel @.***> wrote:

On Thu, Jul 28, 2022 at 04:35:16PM -0700, Gary Buhrmaster wrote:

Although (for "reasons"?), some (many?) guide providers assign channel numbers for the OTTs that are offering (sort of classic) "Live TV" service equivalents such as YTTV (not so the pure streaming services such as Netflix). I can send you a list of the channel numbers that Schedules Direct uses with YTTV if you like, although since no one watches things live, they just record for future consumption, those channel numbers are mostly not useful anyway except for source context.

Is that just for local channels or all channels. I ask because I was directly told just this week by a trusted source that YTTV doesn't use channel nubmers.

(*) I am old enough to remember the parents having a verbal manual remote control, yelling at the kids to change the channel, or turn up the volume.

Ah, come on. I thought you were old enough to remember the most important adjustment -- fixing the horizontal role! Message ID: @.***>

YTTV does not use channel numbers, but SchedulesDirect assigns (useless) channel numbers. If you look at the raw xml data being downloaded from SD, you will see three "display-name" elements, with the third one being a number. I think SD assigns a number just to be compatible with some XMLTV spec.

John

[garybuhrmaster]

Ah, come on. I thought you were old enough to remember the most important adjustment -- fixing the horizontal role!

No prompting was required to fix the horizontal role (well, except for the opening credits for the outer limits), it was an autonomic response by all watching the picture.

[garybuhrmaster]

YTTV does not use channel numbers, but SchedulesDirect assigns (useless) channel numbers. If you look at the raw xml data being downloaded from SD, you will see three "display-name" elements, with the third one being a number. I think SD assigns a number just to be compatible with some XMLTV spec. John

Pretty sure that the XMLTV spec itself does not require a channel number to be provided, but many (many many?) applications expect there to be a channel number available because they (or their users) are fixated on the legacy of the channel numbers existing and having meaning. I would suggest instead that only content matters. Stations, and channel numbers and names and frequencies/program-id's do not (they are simply an interesting historical artifact as to how content used to be made available).

[paul-h]

No, the only assumption I made, and rightly so, was that you would quickly jump in to resurrect this old, tired point. :)

I honestly don't remember having a previous conversation about this with you or anyone? If we have then I apologise. All I want you to do is see there maybe other opinions on the subject :)

[paul-h]

Pretty sure that the XMLTV spec itself does not require a channel number to be provided, but many (many many?) applications expect there to be a channel number available because they (or their users) are fixated on the legacy of the channel numbers existing and having meaning. I would suggest instead that only content matters. Stations, and channel numbers and names and frequencies/program-id's do not (they are simply an interesting historical artifact as to how content used to be made available).

I like the ease with which you can find something with a channel number using remote controls with numbers on them :) I could be alone in using MythTV the way it was intended to be used.

Hell even Netflix and Amazon Prime have there own channel numbers on the UK TiVo \0/

Maybe it is just what I and I believe many international users are used to.

[kmdewaal]

Thanks for the comments and the lively discussion. It is good to focus on features and usability for once.

I like the ease with which you can find something with a channel number using remote controls with numbers on them :) I could be alone in using MythTV the way it was intended to be used.

I am completely with paul-h on this one. Channel numbers define the channel order, it allows for easy channel selection with a classic IR remote with only number keys and my TV shows the same channel numbers. If we would ever drop this it would alienate many users and I do not think it would attract new users. I also think that it does not influence the implementation of the new automatic channel group feature.

I doubt setting up the automatic groups would take much time but doing it at every backend startup doesn't seem right. What about only doing it when the videosources or channel priorities change?

This is a good point. All the tables that influence the automatic channel groups can only be modified from within mythtv-setup so it makes more sense to do this in mythtv-setup. For simplicity I think it is best to do this always when mythtv-setup exits. In my test setup the automatic channel groups are re-created in less than 0.3 seconds.

Long story short, I'd like to see an option to your automatic, channel groups to include a Priority Channels group and only include priority channels in the videosource groups.

This factors out in two different options:

• Create an automatic channel group Priority Channels with all channels from all videosources that have recpriority > 0
• Only include channels with recpriority > 0 in the videosource groups.

The mythfrontend configuration page Setup / Video / General / General (Channel Groups) looks to be the place to add these two options. It is not ideal to put options in mythfrontend that are to be used by mythtv-setup but doing part in mythfrontend and the other part in mythtv-setup is does not feel good. Also mythtv-setup is supposed to be integrated in mythbackend/mythfrontend as I understand it so that is also a reason to add this to the existing configuration page.

Keeping the spirit of the Agile way of working I intend to deliver the first version (minimum viable product) as soon as possible into master. This will then have the functionality as described and implemented but with the channel group generation done in mythtv-setup and not in mythbackend.

Next steps after the first version:

• Priority Channels
• Optimize/simplify/improve the code by using the database to mark a channel group as Automatic instead of matching the name of the video source.
• Replacing the full channel list with the selected Channel Group in various (?) places
• Add option to select the Channel Group in various (?) places

Finally, in the category "you can always dream about it", it would be great if I could schedule a recording from a specific video source. For instance, if I would have the "Astra-2 SCR" channel group selected then a recording should be made from that video source and not for instance from "Astra-2" (same satellite but via DiSEqC switch and not via SCR) or from "Astra SatIP" (same satellite via SatIP box).

[stuarta]

On 29/07/2022 03:05, David Engel wrote:

I do think you're too focused on the EPG use case, though. Do you ever use the other, showings feature or other, guide, search screens? If you do and see 3, 4 or even more entries for every showing because the same channel has multiple numbers, you might start to think differently.

I am also firmly in the channel number camp.

We have channel names, which get copied to callsign so stuff works internally in mythtv.

On DVB-T (terrestrial) the only time you will see duplicate channel names is if they are in the middle of a channel move. Normally there is only 1.

On DVB-S (satellite) there can be multiple of the same channel, but the intention codified in the ETSI specs is that you select the Bouquet which is relevant to your region (ie. England, Scotland, Wales), and the result is there is only 1 version of the channel.

However we don't yet deal with Bouquets, so that's a whole different kettle of fish

Regards Stuart

[kmdewaal]

On DVB-S (satellite) there can be multiple of the same channel, but the intention codified in the ETSI specs is that you select the Bouquet which is relevant to your region (ie. England, Scotland, Wales), and the result is there is only 1 version of the channel.

However we don't yet deal with Bouquets, so that's a whole different kettle of fish

Stuart, you will be pleasantly surprised by the capabilities of MythTV. See the Wiki https://www.mythtv.org/wiki/Channel_Scanning#4._Video_sources and https://www.mythtv.org/wiki/DVB_UK.

[gigem]

I honestly don't remember having a previous conversation about this with you or anyone? If we have then I apologise. All I want you to do is see there maybe other opinions on the subject :)

It was probably one of our other Brits, then. It's a tiresome argument that comes up every time callsigns are mentioned. Most radio signal broadcaster have callsigns. Whether they choose use it in their branding is up to them. Regardless, all channels have a callsign or an abbreviated name they are know by and MythTV uses that name when it's applicable.

[gigem]

I am completely with paul-h on this one. Channel numbers define the channel order, it allows for easy channel selection with a classic IR remote with only number keys and my TV shows the same channel numbers. If we would ever drop this it would alienate many users and I do not think it would attract new users. I also think that it does not influence the implementation of the new automatic channel group feature.

Nobody is removing channel numbers. If/when it happens it will only hide them and be totally optional.

This is a good point. All the tables that influence the automatic channel groups can only be modified from within mythtv-setup so it makes more sense to do this in mythtv-setup. For simplicity I think it is best to do this always when mythtv-setup exits. In my test setup the automatic channel groups are re-created in less than 0.3 seconds.

Don't forget the services API. Changes made there could also affect the channel groups.

Finally, in the category "you can always dream about it", it would be great if I could schedule a recording from a specific video source. For instance, if I would have the "Astra-2 SCR" channel group selected then a recording should be made from that video source and not for instance from "Astra-2" (same satellite but via DiSEqC switch and not via SCR) or from "Astra SatIP" (same satellite via SatIP box).

MythTV already has a preferred input feature. That's not exactly what you want but can suffice if your schedule isn't too complicated. I'm reluctant to hard code more, very, specialized options to recording rules. What would probably better is to add a "This source" recording filter. That's pretty easy to do. There's also the option of using custom rules if you don't need to use the option all the time.

[paul-h]

It was probably one of our other Brits, then. It's a tiresome argument that comes up every time callsigns are mentioned. Most radio signal broadcaster have callsigns. Whether they choose use it in their branding is up to them. Regardless, all channels have a callsign or an abbreviated name they are know by and MythTV uses that name when it's applicable.

I'm sorry David you are wrong. That might be true in the USA but it is not true in large parts of the world. Broadcast TV and radio in the UK definitely do not have callsigns and I have extensive experience with both analogue and digital satellite tv and radio broadcasts in the rest of Europe and can't say I have ever seen a callsign used there. As Stuart told you we actually have to make up a callsign so MythTV will work.

@kmdewaal made a good point about how channel numbers define their order. I would also go further and say in many tv broadcast system it can also define what category a channel belongs. For example on the UK TiVo entertainment channels start from 101, sport from 501, news from 601, kids from 701 etc. So lets say you want to watch Sky News or see the schedule but don't know the exact channel number you can start at 601 and scroll from there to find what you want.

I'm not trying to be an arsehole here I'm trying to make you understand how we use channel numbers and don't use callsigns :)

[paul-h]

@kmdewaal to be clear I'm not against your patch it seems a good idea it was just David's comment below I'm a little concerned about.

EDIT: I will add if it is optional then I'm OK with that :)

I've toyed with the idea of mostly doing away with channel numbers and only displaying callsigns. The current default is to collapse channels that have the same channel number and callsign into a single channel in the EPG and elsewhere. This change would optinally collapse channels using only callsign.

[gigem]

It was probably one of our other Brits, then. It's a tiresome argument that comes up every time callsigns are mentioned. Most radio signal broadcaster have callsigns. Whether they choose use it in their branding is up to them. Regardless, all channels have a callsign or an abbreviated name they are know by and MythTV uses that name when it's applicable.

I'm sorry David you are wrong. That might be true in the USA but it is not true in large parts of the world. Broadcast TV and radio in the UK definitely do not have callsigns and I have extensive experience with both analogue and digital satellite tv and radio broadcasts in the rest of Europe and can't say I have ever seen a callsign used there. As Stuart told you we actually have to make up a callsign so MythTV will work.

There is a lot more to the world than just the US and Europe. Norht and South America and important parts of Asia have them. In addition, what I call callsigns are not limited to officially licensed ones. Cable channels don't officially have them but TV service providers "make them up" too. Since there are really only two, main, guide providers here, those made up names tend to be standard across providers.

Perhaps you're hung up the officialness sounding of callsign. Would it help if I called them mnemonic, station IDs? That's really all it is at this point. I use the term callsign out of old, habit. FWIW, it's called station in some of the database tables and Daniel K. called scheduling ID in some code.

For example on the UK TiVo entertainment channels start from 101, sport from 501, news from 601, kids from 701 etc. So lets say you want to watch Sky News or see the schedule but don't know the exact channel number you can start at 601 and scroll from there to find what you want.

I think you just proved my point. When someone is used to using a single provider, it's easy and understandable for the channel numbers and station IDs to become synonymous. What happens when that user changes providers? Unless there is some central authority over there which tightly controls channel numbers for all providers, that channel number to channel relationship gets broken and has to be releanred. Station IDs as used in MythTV are independent of channel number and provide some consistency across providers and lineups.

I'm not trying to be an arsehole here I'm trying to make you understand how we use channel numbers and don't use callsigns :)

I'm done commenting.

[garybuhrmaster]

Perhaps you're hung up the officialness sounding of callsign. Would it help if I called them mnemonic, station IDs?

How about calling them RFC 2838 Uniform Resource Identifiers for Television Broadcasts (standards are wonderful things, and everyone should have a few to ignore).

[paul-h]

There is a lot more to the world than just the US and Europe. Norht and South America and important parts of Asia have them.

If we are playing that game then I raise you China and India. Aren't they the two most populated countries in the world? Doesn't look like either use callsigns. But they aren't important countries in Asia to you?

In addition, what I call callsigns are not limited to officially licensed ones. Cable channels don't officially have them but TV service providers "make them up" too. Since there are really only two, main, guide providers here, those made up names tend to be standard across providers.

Perhaps you're hung up the officialness sounding of callsign. Would it help if I called them mnemonic, station IDs? That's really all it is at this point. I use the term callsign out of old, habit. FWIW, it's called station in some of the database tables and Daniel K. called scheduling ID in some code.

Doesn't matter what you call them the point is many countries don't use them they use channel numbers to identify channels.

Lets be clear I'm not saying we should not use some form of identifier internally and like I said if you want to make changes to hide the channel numbers and force user to navigate by callsign and use the callsign everywhere in the UI then that is OK if it is optional. You even said yourself it should be optional so there must be some doubt in your mind that what you are suggesting may not be what everyone wants. What I and others want is for you to respect their opinion and keep the option for them to see channel numbers in the UI and to be able to navigate the EPG etc. using channel numbers.

I think you just proved my point. When someone is used to using a single provider, it's easy and understandable for the channel numbers and station IDs to become synonymous. What happens when that user changes providers? Unless there is some central authority over there which tightly controls channel numbers for all providers, that channel number to channel relationship gets broken and has to be releanred. Station IDs as used in MythTV are independent of channel number and provide some consistency across providers and lineups.

The subject of LCN's and EPG channel numbers and how the various providers make money from broadcasters so they can get prime locations in the EPG is a complex subject here in the UK which I wont go into but you are correct the channel numbers do vary from one provider to an other. Most users will only have one provider though so just use the channel numbers from the one they use. It's not a problem in reality it's like driving on the left it's what we are used to so makes perfect sense to us just as I'm sure driving on the right makes perfect sense to you. Neither is right or wrong they are just different and I think channel numbers or callsigns are the same. There is no reason both can't co-exist in the world or in MythTV.

[paul-h]

How about calling them RFC 2838 Uniform Resource Identifiers for Television Broadcasts (standards are wonderful things, and everyone should have a few to ignore).

You probably said it in jest but I guess if they were more widely used they could be used in place of the callsign internally at least to link channels from different providers.

A quick search didn't find much info about them I did see that XMLTV has a proposal to use them not sure if they ever got anywhere with it.

[garybuhrmaster]

You probably said it in jest but I guess if they were more widely used they could be used in place of the callsign internally at least to link channels from different providers.

It was not really a jest. but it is important to understand that the RFC was not standards track, and no org was ever asked to start registering the names (I could easily imagine various orgs (ICANN, ITU?) wanting to be the registry of record, since the names are DNS-like and were expected to need to have equivalent registration and dispute resolution processes, should it have actually moved to full standardization).

A quick search didn't find much info about them I did see that XMLTV has a proposal to use them not sure if they ever got anywhere with it.

XMLTV "strongly" recommends using RFC2838 channel id's, and at least some grabbers are RFC2838 compliant-ish, but there are grabbers that were not the last I looked, and since there is no registry of URIs, full compliance testing is not possible (although those grabbers that use barewords for the channel-id are not going to be compliant).

However, they are not a panacea, as they are scheduling entities, and not transmission entities. So (using the US as an example) two different sub-channels on the same (or different) transmitters might have the exact same schedule, but one transmits in SD, and another in HD, and, at some future time, UHD (and some people will choose to record one in preference to another). One must understand the various layers of abstraction in the entire chain. Again, using the US example, if that station is being broadcast on two different transmitters, typically for geographic coverage reasons, their official government registered transmitter ID (as every transmitter must be individually registered (and assigned a callsign in the US, perhaps a license or registration ID elsewhere)) is different, and even while the physical ID (and tuning information) is different, there can be virtual numbers and display names added to assist (confuse) the consumer. That MythTV provides ways (although sometimes those can require contortions) to be able to differentiate and support most of the variations is a great advantage of the solution, although that flexibility can certainly confuse the many who have much simpler requirements.

[kmdewaal]

The "Channel Group per Video Source" feature is now committed with largely the functionality as described earlier. The following review comments have been processed:

• Database entries are only changed when needed and not deleted/re-created. This is a bit cleaner but it does not save processing time.
• An automatic channel group "Priority" with all channels that have the channel.recpriority field set to a value bigger than 0.
• Updating the automatic channel groups is now done in mythtv-setup and not at the start of mythbackend. As the database values that influence the automatic channel groups can only be changed from mythtv-setup this is for now a good solution.

The functionality to manually maintain the Favorites channel group and to add other manually maintained channel groups is not changed. In addition to adding channels from "All Channels" to Favorites and other manual channel groups it is possible to add channels from any automatic channel group to a manual channel group.

Review comment that is not yet processed:

• Optionally show only the priority channels in all automatic video groups.

About using the Channel Group in more places. The current implementation does now have Channel Groups that are manuallly maintained (e.g. Favorites) and that are automatically created (Priority and the groups per video source). However, there is no group for "All Channels". The way it works is that id -1 is used to indicate "All Channels" and the values are taken from database table channels; id values > 0 are used as index in channelgroupname and this then gives chanid values with which database table channel can be accessed. This is something that does require "iffy" code everywhere channel groups are used. I think it would be simpler if there is also a channel group "All Channels" so that every channel group can be accessed in the same way. That would make it easier to use the Channel Group in more places.

What still needs to be done:

• Create a service API entry for ChannelGroup::UpdateChannelGroups() This is the function that is called at the end of mythtv-setup and that does update all the channel groups. When the configuration is not anymore done with mythtv-setup but with the service API then this function must be called after all configuration is done.

A bit of help about exactly what and where must be changed for this will be greatly appreciated!

[kmdewaal]

20220803-videosourcechannelgroup-v32.patch.gz

This patch is functionally identical to what is committed to master but it can be applied to fixes/32.

[paul-h]

We generally don't backport feature patches to any fixes branches only bug fixes.

[kmdewaal]

Looks like the software police a.k.a. tidy & clazy is rather unhappy with my latest. Will have a look at it.

[kmdewaal]

I have been using this for some time now and I think it is finished. Adding more functionality would also require more user interface elements and more logic and for now I consider that a case of "the best being the enemy of the good". Probably the forthcoming web-based GUI is the best place to extend user interface functionality. Closing this ticket.