Use of "channel-id" with m3u4u, "backup" URLs for the same channel

I'm using m3u4u to filter down my m3u playlist, rename channels, provide XMLTV and channel logos, etc. I've loaded the M3U and XMLTV URLs directly into Channels DVR from m3u4u, and things seem to be working well. I just have a few questions regarding my current lack of "channel-id" tags in my current setup and whether it's an issue.

  1. Is the channel-id tag truly necessary for m3u playlists? M3U4U doesn't seem to provide or support that tag by default, and my channels still seem to be listed in the guide properly.. If necessary, how should I go about configuring the "channel-id" for all my channels en masse on m3u4u? Or do I need to download the M3U file and manually add the "channel-id" tag for each channel? That seems tedious..

  2. I have configured my M3U playlist to contain a number of backup channels I would like to use in case the primary goes down. Specifically, I have configured multiple channels to all have the same channel name, just pointed to a different URL. When loaded into Channels DVR, each channel displays the same channel # and they're all stacked one after the other in the guide (as designed). How can I tell if Channels DVR is truly loading the different URLs for each channel? Is it possible the system is just ignoring the other URLs for these channels? Or do I need to manually add in different channel-id tags to achieve what I'm looking to do? (See question 1 above).

Thank you in advance for any help.

If channel-id is missing then tvg-name is used.

If that's missing too, an ID is made up using the position of the channel in the list. This is not reliable if channels are added or removed and channels shift around.

IDs must be unique and if there are duplicates they will be ignored.

For backup behavior you could try a second source that uses the same IDs, but I'm not 100% if that works.

Thank you! M3U4U uses tvg-id so I should be alright there, you're saying? I can disregard channel-ids?

I'll continue playing around with the backups..

tvg-id is used to map to guide data and is not unique. I mentioned tvg-name is used as a fallback.

1 Like

Thanks again - Makes sense!

I'd like to set this up as suggested (specifying channel-IDs for each channel), I'm just not sure how to do so in tandem with M3U4U (or if I should move to a different service for this type of capability).

1 Like

I would actually like to find an m3u editor that could add channel-id en masse. I know M3U4U does not have that capability, or if any editor out there does for that matter. It’s too much of a PIA to do it manually.

Any text editor worth its salt should support Regexes, and coupled with a sed one-liner you could do it with a single command.

1 Like

Thank you - I'll look into that. Minor problem, but this means I'd have to save/store the M3U locally, vs just pointing to the M3U URL in m3u4u, which I was trying to avoid doing. Sounds like I'll need to, though, in order to get what I want :slight_smile:

This would fall under a feature request, but is there a way that "CUID=" tag could be recognized by the server? In doing some research, it looks like "CUID=" is the same as "channel-id=" (but correct me if I'm wrong). I've found that IPTVEditor will add "CUID=" to m3u files without a unique channel ID making life much easier. My use case for this would be so that channels are not deleted from collections if the name of the channel changes.

Since the CUID tag isn't a standard and it stands for ChannelUniqueID
It appears to be used as a fallback in some software when channel-id is missing.

For anyone that's interested, I ended up using IPTVBoss to configure my M3U playlists moving forward. Their M3U output includes the "tvg-name" variable, as mentioned above.

Haven't gotten around to messing with backup channels, but will circle back to test the suggestion from @tmm1 above (secondary source with same IDs).

1 Like

Can you please provide some examples from your M3U of what CUID= is set to?

We've seen some issues trying to use that, because it appears to be generic numbers and when you add multiple different M3Us they overlap even though the channels are different.

I think that’s the issue I was having that was screwing up my channel collections. I have multiple playlists that I run through IPTVEditor, and it looks like it assigns generic CUID starting with CUID=“1” and progressing from there. I assume with multiple playlists, then it would give me overlapping CUID.

I'm going to remove the CUID usage then

This probably goes to show my ignorance of how all this works, but can there be a way for channel collections to recognize channels by their actual assigned channel number instead of their “channel-id” so if the channel name changes, (but channel number stays the same) the channel will not disappear from a collection?

No, the entire system depends on channel-id because numbers are not stable or unique either.

1 Like

There is a reason that the M3U–based Custom Channels documentation states that channel-id is a required tag in the playlist.

The documentation is there to guide you to ensure that you are following requirements. If you cannot follow the guidelines, then you should be ready for unexpected results.

(Personally, since the channel-id tag is specifically mentioned as required—and is the only tag listed as required—the M3U parser for Custom Channels ought to reject/disqualify any playlist/entry that does not include this tag. Think of the dozens of posts that could be weeded out and support issues avoided if the stated requirements were actually required.)

1 Like

Geez. Sorry I asked.

No need to be sorry.

  • The OP was informed that if channel-id was missing, tvg-name would be used; duplicates would be ignored.
  • You asked about adding channel-id tags en masse, and I recommended using crafted regular expressions to achieve this goal.
  • You mentioned a tool that uses CUID tags, so support was added. (However, it turned out that the generated CUID tags were not actually unique, and therefore weren't actually useful, so support for them was removed.)

My point was that all of this back-and-forth and troubleshooting would have been needless if the requisite channel-id tags were present, as the documentation states they need to be.

1 Like

racameron:
You do nothing to contribute towards the improvement of Channels with this work philosophy, and in fact, kill possible opportunities for improvement. If no one ever breaks the rules of documentation, nothing ever changes. This is a community, is it not?? And as such, those possibilities for improvement come from everyone and anyone all working together collaboratively. I believe it was clear the OP knew they were breaking those rules.

1 Like