Azuracast: Questions and ideas related to my use case

[xewl]

• Installation Method: Traditional on Ubuntu 16.04 (at the version from the end of #405)
• Host OS (if using Docker): /

Describe the issue in full detail, including screenshots if possible:

This is more of an underlying question.
I've had a request to have a fall-back mount for the live mounts.
I've set up the Station as follows:
/stream.mp3 (default)

• Live-streamed via source at 196kpbs
• fallback: /mobile.mp3

/mobile.mp3

• Live-streamed via source at 64kbps
• fallback: /_.mp3

/_.mp3

• Liquidsoap AutoDJ at 128kpbs with about 100 random songs & some jingles (for now).
• fallback(default): /error.mp3

I notice that the playlist only includes the songs of the default mount, also falling back to the songs from the fallbacks, when out. Which is good!
Up next still shows the songs next-up in the AutoDJ, but they don't end up in the playlist (if not fall-backed upon).

The main question is: is this a viable set-up, and can I improve this somehow?

Ideas floating around:
• What's the best mount point to share on external streaming platforms, or might it be better to set-up a proxy on the main domain name/server and share that one? (in case I need to switch to another server)
• Is it possible to update the /error.mp3 fall-back file being used (per Station/application-wide)?
• Is it possible to define (sub)domain names on the application router, and route them to the public page (maybe also nginx)
• Is it possible to relay, a mount point on the same server/station to a mount point and transcode it into a lower bitrate -from within AzuraCast, configurable as a StationMount->type(mount/autodj/relay) -? Gist snippet
All of the above floaters also include the following question:
Would it be a good Pull Request to eventually make to this project, by me or any of our committers?

[SlvrEagle23]

@xewl Your use-case is definitely supported by AzuraCast, but in a different way than you probably have set up right now. To achieve this, you should have two stations:

• One station with LiquidSoap enabled and a single mountpoint that provides the always-running AutoDJ, and
• One station with backend disabled, with mount points for the live streaming, which have "fallback URLs" set to the URL of the first station's music stream.

Since each AzuraCast station, for the sake of ease of configuration, is assumed to have only a single song playing across all mount points at all times (which is, in many cases, a safe assumption), setting up two stations will ensure that both are properly aware of what's playing in their environments without conflicting with one another.

[xewl]

It's not really conflicting at this very moment, except for the "coming next" data.
It was even working better than expected in this set-up! (Wherefore kudos btw..)

I actually had set up "Fall-back stations" for each Station, as the fall-back music on two streams couldn't be mixed with the used genres. If I had to set up just one fall-back station, that would've been the obvious way to do it and I'd play an "elevator waiting music"-clip all-round and set that as fall-back everywhere... 😛

Regarding /error.mp3 that would still mean you'd have to set up the new value for every StationMount you create, right? (Can a fall-back mount even be from another station instead of on the same? 🐙 )

I currently run 3 -totally different- Stations on this set-up, all managed by friends, externally.
That's 3 -totally different- stations, externally managed by some friendly people with totally different tastes, and setting up fall-back Stations for that purpose, then having to give access to that account is also tiring to my brain (UX). /rant

I'm going to be a bonehead for now, and leave this 1 Station set-up in its current state :trollface:

I've seen you use "type" for Playlists, and was wondering if StationMounts could use such a set-up too. I definitely think it could be useful, though I tend to overcomplicate the stupidest things. (:

I'm aware that related code should be reviewed too, and that there's a difference in SHOUT vs ICE regarding relays/transcoding. But I just might give it a try and investigate the possibility someday.

[xewl]

I do see how a second Station can be a benefit.
Some settings for StationMounts regarding AutoDJ threw me off.
I just see some overhead regarding ICE/SHOUT-servers running because of those extra Stations.
But the fallbacks being split from the original Station is also positive in a way.

Switching it over (as per your suggestion) again ¯\_(ツ)_/¯

The other questions are somewhat unrelated, so I'll be closing this one.
Thanks for your input on this 👍

[xewl]

I can't seem to use the "Fallback mount" option outside of the station's scope using eg. localhost:8000/radio.mp3 as a value. So I added a mount with a Relay Stream URL instead and then set that relay-mount to be the fallback instead.

Do you notice why I find this so unclear and resource wasting? (:
I must still be missing something, this seems so dirty and a waste of resources (even though I shared the media folders and turned off Liquidsoap on the Station with live mounts).
Also; seeing the option "Enable AutoDJ" on StationMounts, when the Station itself has it turned off, is confusing too, 😛

[SlvrEagle23]

@xewl No doubt, there are some enhancements that can be gleamed from this discussion, though admittedly the back-and-forth here is a bit too "stream-of-consciousness" to count as a request for an enhancement itself.

I understand what you're looking for, but in some regards the limiting factor here isn't AzuraCast but rather the way the underlying software handles fallback points. If it doesn't support a URL as a fallback, then there's no way for us sitting on top of it to force it to, without just creating a fake new mount point that is the "Relay URL" style, which is something we _can_ do, it's just a little more complicated than it looks on paper.

I don't personally mind the open-ended discussion style here, as long as when it comes to actually building out these enhancements, you can distill these thoughts into some concrete changes that could be made in AzuraCast that would help you out.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.