Duplicate channels in Channels Collection

Channels collections on Android TV client are showing duplicate channels if multiple providers are available.

For instance, if I have a manual source for Pluto TV streams and a source with Pluto TV feeds pulled from mjh.nz, both channels are appearing in the Channels Collection, even if I only have the collection set to pull in one channel.

Example: I have "TV Land Sitcoms" set for channel 609 in a manual source file, but the channel is also pulling in from the mjh.nz Pluto TV file in a separate source, where it's available on 20204. My "Entertainment" channels collection is only set to pull in 609, but it's showing both 609 and 20204 on my Android TV client.

This problem isn't replicated on iPhone and Apple TV clients, just Android TV. Toggling different Stack Duplicates options doesn't solve the problem, either.

1 Like

To add to this, the duplicates seem to happen when the same M3U8 URL is used on multiple channels.

So, to go back to that TV Land Sitcoms example, I have 609 in a Custom Channels list with "text" selected as the source and manual entries for different Pluto TV feeds (so I can have them appear on the channel numbers I want). As a backup, I also have a Custom Channels list called "Pluto TV USA Alternate" with URL chosen as the source and a URL to the mjh.nz Pluto TV file for the USA.

Since both sources are pulling from the same M3U8 URL for TV Land Sitcoms (one inserted manually, the other pulled directly from the Pluto TV file on the mjh.nz website), I'm guessing that's why the duplicate is appearing. Strangely, this only happens on the Android TV client (a TiVo Stream 4K) and isn't replicated on iOS or Apple TV.

Saw this was already tagged as an Android bug, just wanted to offer more context.

Just curious if anyone is going to acknowledge this bug...

To avoid dupes the channel-id in your m3u should match

Curious why this is only the case on Android TV? Duplicates don't appear within channel collections on Apple TV and iOS...

The apps are completely separate with their own code

There is no way to fix the buggy code within the Android TV app?

Of course there is a way to fix it. It was merely being pointed out that one does not carry over to the other.

I am sure the bug report is appreciated by the developers. However, it ought to also be noted that the Android and Apple clients are completely separate entities. (Hence why there are several features in the Apple clients that are not yet available in the Android clients. Also, remember this is a small team 3 guys, not some big development firm.)

Unfortunately, some of these channels don't have channel IDs.

For instance, The Guardian FAST channel pulled from the Samsung TV Plus UK has two tvg-id tags associated with it, but no channel ID tag — and, since I don't control that file, there's no way for me to assign one to it.

Without channel-id tags, your custom channels will not give you a great experience within Channels. (The very first requirement regarding custom channels listed in the documentation is the channel-id tag; and yes, it is listed as being "required". In fact, it is the only tag listed as being required.)

As mentioned, the issue of duplicate channels within Channel Collections is not a problem on Apple TV and iOS, so this seems like an issue that the devs could fix on Android TV, should they want to.

Which is fine, but as I also mentioned, there are people who provide M3U lists who don't implement the channel-id tag feature. One example I gave is the Samsung TV Plus lists that are published here; the list for the UK (GB) doesn't include channel-id.

I understand the code that powers the Apple/iOS apps and the Android apps are unique, but since Android TV is the platform I mainly use for Channels, it's important to me that duplicates aren't shown — or there is a way to hide then en masse.

Also, a little frustrating that it took a week to get some kind of response to this.

This thread was marked with android-bug label and is on our development radar. It has to reproduced and isolated so the part of the code responsible can be found.

If you're expecting a quick fix then unfortunately that is not possible in this case.

Is there something I can do to help you guys replicate the problem? I've seen developers ask for logs in other threads, but no one has asked me for anything here — not a log, not a screenshot, not anything. I'm happy to provide whatever information or account access I need to, so developers can replicate the experience. I thought my description of the problem was sufficient, but maybe not.

We have your server diagnostics from Dec 12. If anything else is required we will ask for it here.

The guide data code is more complicated than you can imagine so I'm sorry but this isn't a quick fix or something we can copy paste from the Apple app to Android.