OK, great I will adjust my M3U files. Thanks
I do still think though that it would be good to have a way to ignore/delete a specific HDHR tuner completely. It feels wrong to have sources showing that aren't meant to be sources especially if you then have to take into account what channel-ids they are using.
Yes that would be good
I've just tried again with my own channel-ids (I used GT1 GT2 etc), and the text is still getting overridden by the HDHRs. It is like the HDHR wants to call Ch 1 "BBC One S West" and nothing is going to change it's mind!
In the WebOS Guide page:
Either of my individual M3U sources selected and Ch 1 BBC ONE SW HD
All Sources selected and it changes to Ch 1 BBC One S West (the SD channel name)
Have you dried disabling the HDHR from within the client app on your device? (Settings > Manage Sources > HDHR device > Enabled)
What you are describing sounds like the HDHR tuner has higher priority in the source list on the client device. Moving the M3U playlist you created higher in the list, and/or disabling the HDHR from within the app (not on the DVR web UI) ought to fix what you are experiencing.
All HDHR tuners are disabled on all Client apps and the providers removed on the server. They can't be defeated! I tell you, they are the cockroaches of the AV world!
Then you need to submit diagnostics from a client app, as what you say you've done, and what you say you're experiencing/seeing, don't match up.
After that, email support, because I don't think there's anything more the community can do to help.
I am happy to try anything to sort this out as it's driving me crazy but I don't see what it has to do with the clients.
The server sees the overridden incorrect text for Channels 1-7 directly on the WebOS when all sources are selected in the Guide section, but not when a single m3U source is selected. So even if I had no clients at all that would still be an issue.
Now I'm confused. Are you saying this is only a problem when viewing the guide in the web UI, and "All Sources" is selected? Other than that single situation, you don't experience any issues with guide overlap or display within the client apps?
If that is the case, I guess I misunderstood your concerns. Also, if it is only within this limited case that is causing issues, I am not certain I see this as significant an issue as it would otherwise be.
No, it is a global issue. Whether it is on the server WebUI guide page, any of the clients, in the API, the channel name text reverts to the description the HDHR tuners would give to that channel number if they were active.
When I managed to delete the HDHR tuners for a short period using the curl commands all was well and the channel name was correct everywhere. But they were re-discovered and the problem came back.
So I think it has to be coming from the HDHR tuners.
Are you using the tvc-guide-stationid tags as mentioned in your other thread? If so, it will supply not only the guide data for that channel, but also the channel name and logo.
Yes, for the channels I have changed numbers of I am. See my first post for an example entry. The channel-id has since been changed to "GT1"
I think the way to summarise the situation is that the system is behaving exactly as I would expect if the HDHR tuners were still active. Every part of this problem could be explained if they were. But they aren't meant to be. The provider for them has been removed at the server side and all clients have them disabled.
I have seen some strange behavior also, but haven't documented it.
I have Channels DVR running in docker containers and when they ran with bridged networking they couldn't see my HDHR tuner, which was fine.
Now that I changed the docker container to run with host networking, they all see my HDHR tuner.
Even though I haven't selected a provider for the HDHR tuner, the channels appear in some places, including the web UI guide sometimes. They appear in /devices/ANY/channels on all my DVR's.
I have one more option for you to try: disable all of the channels on the HDHR tuners (from within the HDHR's own webUI). You can still tune them directly, so your M3U playlists within Channels will work, but Channels will see that the channels have been disabled, so it will not display them or attempt to assign guide data to them.
(If you are using AppleTVs, it would be best to delete the app from your device, make this change, and then re-install it. Settings, including channel states, are preserved on the client and don't reflect changes made in other places. A fresh (re-)install will ensure that no old settings are retained.)
Otherwise, I'll reiterate what I previously stated. Move your tuners onto a separate subnet, or block port 65001 via your firewall/router. Either option ought to result in your expected behavior.
I can certainly understand the goal you are trying to achieve, but you are obviously running into edge cases because you are not quite using the software as designed. When remapping channels I never ran into this problem, but that was probably because I was not trying to reuse a channel number supplied by a physical tuner.
Also, one good rule to adhere to when making changes to your lineup, changing channel numbers, adding/removing sources, etc.: after you have made a change, restart the Channels DVR server process, and then within the webUI do a "Delete and recreate guide database".
(Edit: port number was off by one.)
I already have. Every channel in every tuner is disabled directly on the HDHR web server page. Interestingly though I've just checked on one of the clients and when I go into the tuner source list it is showing some disabled and some favourites. My guess is because it hasnt been enabled it hasn't been syncing? Maybe a eureka moment? No sadly. I synced the favourites/hidden on all the tuners so that every channels showed disabled, but still the wrong damn text appears!
I only have a basic ISP supplied router so I'm not sure if I can do that. It has port forwarding but I can't see anything about port blocking. I'll google it and see if its possible.
Clients don't sync their channels status (favorite/enabled/disabled) beyond their first run. If you modify a channels' state on a client, that client will continue to honor that setting, regardless of what further/later changes you make. (That's why I said you should completely re-install your client apps after making these changes.)
The status of every channel changed to the 
disabled sign when I synced it on the client settings page. It gave me the option to sync from the source (which I chose) or export to the source. This is on android clients.
Is the proper disabling of the HDHR tuners something that can be implemented fairly easily/soon?
Despite trying your suggestion of different channel-ids, the channel name problem still exists.
I have searched all of my M3U files for the exact text strings that are appearing as the Channel names and they do not appear in any of them, so the name has to be coming from the supposedly disabled HDHR tuners.
I don't think my router can implement the port blocking or subnet suggestion so if it can't be fixed at your end I may have to give up and go back to the HDHR forced channel numbers.
This is looking like it might be my only option. My tuners are currently connected into the same unmanaged 4 port switch and are allocated reserved IPs in the DCHP table of the main (only) router. If I get a managed switch to replace the unmanaged one how would I set that up so that the tuners can still be accessed via the M3U file/custom source but not by Channels directly? Thanks for any help.
A managed switch is not going to magically make that possible. You need to make the additional subnet in your router, not the switch.