Azuracast: Playlist of remote MP3 URLs fails to play

[JacobSyndeo]

Installation method
Docker

Host OS (for Docker installations)
Ubuntu 18.04.2 LTS

Describe the bug
Given a playlist with a list of MP3 URLs, AzuraCast apparently fails to play them, simply playing the "AzuraCast is Live!" error message on a loop

Upon delving into the logs (with docker exec -it azuracast_stations bash followed by tail -f /var/azuracast/stations/bronytunes_radio/config/liquidsoap.log), I find this repeated several times:

2019/04/13 06:46:15 [protocol.process:3] Failed to execute curl -sL "http://azuracast.bronytunes.com/carrierwave_uploads/12916/PrinceWhateverer_-_Open_Up_Your_Eyes__Cover__-_01_Open_Up_Your_Eyes__Cover_.mp3" -o "/tmp/liq-processeb9bc5.mp3": ("timeout","19.8795690536")
2019/04/13 06:46:15 [lang:3] AzuraCast Raw Response: http://azuracast.bronytunes.com/carrierwave_uploads/12916/PrinceWhateverer_-_Open_Up_Your_Eyes__Cover__-_01_Open_Up_Your_Eyes__Cover_.mp3
2019/04/13 06:46:15 [single_6423:3] Finished with "/usr/local/share/icecast/web/error.mp3".
2019/04/13 06:46:15 [single_6423:3] Prepared "/usr/local/share/icecast/web/error.mp3" (RID 0).

So I then manually run that cURL command to see what happens, and it works just fine, writing a copy of the MP3 to /tmp as expected. Now, I thought this may be a permissions issue, as I was running cURL as root, but glancing in /tmp with ls -la /tmp showed that the MP3 has been downloaded successfully several times by the azuracast user, despite it thinking that it failed:

To Reproduce
In order to reduce unnecessary complexity, I'm using this very basic one-song playlist while debugging this. I provide it to AzuraCast like so:

Expected behavior
It should play. I've been successfully running vanilla Liquidsoap on my server for years, configured as such:

songs   = skip_blank(mksafe(playlist(mode="randomize", reload=43200, "http://bronytunes.com/[plaintext-song-url-list]")))
jingles = mksafe(audio_to_stereo(playlist(mode="randomize", reload=21600, "http://bronytunes.com/[plaintext-jingle-url-list]")))
radio = rotate(weights=[1,3],[ jingles, radio ])

output.icecast(                                                                                                                                                                           
  %mp3(bitrate=128), fallible=true,                                                                                                                                                       
  mount="/stream-128.mp3",                                                                                                                                                                
  host=BTRHost, port=BTRPort, password=BTRPassword, genre=BTRGenre, url=BTRURL, description=BTRDesc,                                                                                      
  full)

Relevant Logs
(pasted inline above)

Screenshots
(pasted inline above)

Device(s):
Any

Additional context
See the Expected Behavior section for example Liquidsoap code that works with this MP3 list.

[Vaalyn]

I've researched about this particular behaviour and this could be related to a bug in liquidsoap that has been fixed. The version were this fix is included has been released as 1.3.7 3 days ago.

Thread 1
Thread 2

[Vaalyn]

I've tried to confirm if this bug is fixed after the update and put the playlist you posted into the demo installation and before the update it failed like it did for you. After the update it successfully plays the playlist.

Can you update and check if it's also working for you now @JacobSyndeo?

[JacobSyndeo]

Those issues look exactly like what I was seeing, so I'm hopeful that this is the fix. I'll test ASAP, but I'm having some issues getting the web interface to load now. I'll post back here once I'm able to check.

[JacobSyndeo]

Yep, this fixed it! After getting the web interface back up (port mapping issue), I had to work around a different problem at the same time: on my implementation, the links in the text file aren’t pointing directly to MP3s, they’re to a script that redirects to where the files actually are, and liquidsoap apparently has a regression here, as it fails to follow redirects in versions newer than what my server used to run. My solution was to make that script set a content-type header and then simply pipe the contents of the destination file through rather than doing an HTTP redirect. And what do you know, it worked.

Thanks again for the help here!

[Vaalyn]

You're welcome and thank you for helping us diagnose and fix this bug.