Mutiple streams per channel

[vdrover]

A powerful feature of StreamMaster is the ability to combine multiple streams into one channel.

In other words, having backup streams if an existing stream is offline or in use, but within a single channel.

Is that possible currently? If not, is it an interesting feature for you?

[sparkison]

Included in latest dev (sparkison/m3u-editor:dev) if you'd like to test.

To use the feature, simply edit any channel and assign any other channel in m3u editor with your desired failover. You can add multiple, and re-order them to prioritize them.

Channel > Edit:

Failover count on Channels table:

To define a set number of streams to prevent new streams from starting if your playlist has the maximum streams running. This is defined per-playlist, so if the primary channel maximum streams are reached, then the fallback will use the streams available in it's playlist, etc. If set to 0, then we'll assume there is no limit and we can continue.
Playlist > Edit > Output (optional):

[vdrover]

This looks great! I will test. One question first.

I'm using a custom domain, and typically (xteve, streammaster, etc) would take the URL of the playlist and load it into VLC as a Network Source to test playback. It's a quick and easy way to test the proxy/editor without having to add to Plex/Emby/Jellyfin.

For some reason, if I use the download URL of the m3u-editor playlist (eg: https://my.domain.com/9f08w8fd-65e7-4h01-b127-ea4b61hb42e6/playlist.m3u) as a network Source, the channels never load in VLC and I cannot test playback.

Oddly, simply download the M3U and opening it VLC allows the channels to load, and playback to occur as expected. The URL also works if i add it directly to Plex/Emby/Jellyfin.

Am I missing something that allows me to test an m3u-editor playlist as a Network Stream in VLC?

[sparkison]

I'm not quite sure? I'm able to open as a network source in VLC and it works for me. I did push a couple of updates/fixes that may help. I'll do some more testing in the meantime to see if I can find anything.

[vdrover]

Just to be clear, do I need to create custom or merged playlists if i don’t need them?

[vdrover]

Looks like it's working well in terms of adding failovers. I have yet to devise a test for actual switching from a failing stream to an active one (up next), but I have some UI feedback.

When adding failovers, the main channel, and and failovers already added, perhaps should be removed from the dropdown selector? I feel like there is a danger of creating a fatal loop if I add the same channel as it's own failover.

[vdrover]

I created a new playlist with one stream that is confirmed not working. When I downloaded the playlist and opened it in VLC, the channel did not play. I received the expected "VLC could not open the MRL" error.

Then, in the channel editor for the broken stream above, I added 3 failovers with working streams. After saving, I processed the playlist and dowloaded it again just to be safe.

When I opened the playlist in VLC, the channel did not play. I agaon received the "VLC could not open the MRL" error.

I conclude that the failovers were not used.

[sparkison]

hmm, the failover is working in my testing, adding a stream that I no longer have access to, and then adding failovers, the failovers are indeed loaded and played.

Is this with HLS or MPEG-TS streaming?

And I agree on the channel selection, still a work in progress, but we will prevent creating a loop. Still in the testing stages now, so that's coming shortly....

[vdrover]

MPEG-TS. I can connect with you on discord if needed. Available for a video call/screenshare, etc...

[sparkison]

try to add APP_DEBUG=true to the container and then view the logs, there will be an ffmpeg log generated (if not there already) for today with more verbose output. That will at least help determine if things are getting to the ffmpeg process, or failing before.

You might also need to look at the laravel logs. So if you head to /var/www/html/storage/logs, the main app log will be in laravel-2025-05-31.log and the ffmpeg log would be ffmpeg-2025-05-31.log (depending on timezone). There's log rotation implemented, so only three days worth of logs are retained at a time, of there's no log file generated for today, it means no errors were triggered.

Finally, try disabling the Playlist streams available by setting it to 0 (if you haven't already) to rule out stream count tracking issues.

[vdrover]

Thanks for the debug tip!

Here are the logs from my test:

As expected, the ffprobe initially fails (labelled "A" above) as the main channel URL ending in "499s" is not working.

Then it moves to the failover url (labelled "B" above). The title of the failover url is correct ("Sports 1"), but you can see the failover URL ends in 499s also. This is the main URL. The failover url ends in "1661". It is working on it's own. But as a failover I don't think it's being checked.

In other words, I can add a failover url, but the main/broken URL is checked twice, failing both times.

I then added a second failover channel, and the same behaviour: It now worked it's way through the title of both channels, but each time only checking the broken main url ending in "499s".

[sparkison]

This was resolved in a recent push where the URL wasn't resolving properly in some cases. Can you try the latest dev and see if you're still seeing the same? The URLs should definitely be different this time 😉 and thank you for the details and log! Definitely helps 🙌