HDHR tuners refuse to be ignored

Channels DVR Server
#1

I'm in the UK and using 2 HDHR Quattro tuners for my FTA sources.

Because there is no custom channel numbering available, I have created some custom sources that use M3U files which link to the HDHR IP but with some channel numbers editted. This is primarily to move the HD channels 101-107 to what were the SD channel numbers 1-7. I have then removed the providers from the HDHR tuners in the source list so (in theory) they don't do anything.

It is working fine except I'm getting an odd situation with Channel Names which seems like the HDHR tuners are still forcing their data into the system.

EG Within my new M3U list I have moved what was previously Ch101 BBC ONE SW HD to Ch1 (which was originally the SD channel BBC ONE S West) . These are the entry lines for it in my M3U:

#EXTINF:-1 channel-id="1" channel-number="1" tvg-name="BBC ONE SW HD" tvc-guide-stationid="120576",BBC ONE SW HD
http://192.168.1.12:5004/auto/v101

This works fine and I do get the correct HD channel and it's EPG on Channel 1. I know it is using the correct channel as the Web Interface for the HDHR tuner that the M3U links to shows it is tuned to " 101 BBC ONE SW HD" when in use.

Initially the Channel description appeared as BBC ONE SW HD on screen too, but after some while, the channel description text for that channel reverts to "BBC ONE S West" which is the description for the original Ch1 in the HDHR tuner lineup.

It is as if the HDHR tuner gets re-detected or re-scanned and even though it has no Provider data, the channel descriptions are getting read into the system. I even tried marking all channels in the Tuner as hidden, but still the names override my M3U ones.

If I go to the guide on WebOS for the Server and select "all sources" Ch 1 description shows as BBC ONE S West but if I select only one of my M3U sources it shows as BBC ONE SW HD. The only other sources that have any BBC channels are the HDHR tuners so it must still be picking up that data from them. The same happens with the other channels I have changed numbers on - the original name gets overridden if I select all sources but show correctly if I select either of the m3U sources. It is the same on the clients, even with the HDHR tuner sources de-activated, the channel names revert to the original tuner ones.

It does seem bizarre that the system doesn't have a way to completely delete or ignore a device on your network just because it recognises it as something it can use. What if someone had an HDHR tuner on their system that they were using for something else and didn't want to use it at all for Channels DVR? I would much prefer having to give the system the IP address of any tuners I did want it to use rather than it presuming it is going to use anything it recognises.

Anyone think of a clever way to completely keep the HDHR tuners out of it? I previously tried to delete them with a curl command, which worked initially, but they were re-discovered. It's like playing whack-a-mole with them!!

Delay Playing MPEG-TS m3u (8 seconds)
#2

Place them on a separate subnet? Block port 65001/U—which is the port that the HDHR uses to broadcast for discovery—on your network?

(Edit: port number off by one.)

#3

I'm quite sure the developers recognize the problem, in fact Aman has plans to fix this by adding a hide button of some sorts.

#4

Yes, I did see that post when I was searching the issue, but as it was posted over 2 years ago I figured it had been forgotten about. I didn't add mine manually, they were auto-detected so not sure if the curl command to forget the IPs would work, nor do I know what that curl command would be anyway. If anyone knows and that would work with auto-discovered devices I would love to get the system to ignore those IPs permanently.

This is my first real gripe(s) with the system. Firstly, that it doesn't have a proper way to have custom channel numbers, which for such an otherwise sophisticated system I am surprised by. Then as a result of that shortcoming the only way to achieve it with HDHR tuners means you effectively end up with zombie devices on the system constantly overriding your chosen data with their own.

#5

You need to use a unique ID here to avoid conflicts

#6

It is a unique id for any of the active sources. The only conflict is with the HDHR tuners which are supposedly inactive due to no provider.

But do you mean I could put anything in there and it would still work?

#7

Yes change it to bbc-one or anything else unique that's not "1"

#8

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.

#9

Yes that would be good

#10

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)

#11

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.

#12

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!

#13

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.

#14

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.

#15

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.

#16

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.

#17

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.

#18

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.

#19

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.

1 Like
#20

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.)