Support Shoutcast2

[Nicholas Vrtis]

I am running Windows 7 64 bit.

I have Mixxx 1.10.0 installed, and it plays music fine.

I have Shoutcast DNAS (v.2.0.0.29) installed on the same system and it 'appears' to be working (no error messages when I start it up at least).

I have gone to Preferences->Live Broadcasting, and think I've got everything set up OK.

When I try to Enable Live Broadcasting, I get an error message from Mixxx that it failed to connect to the server.

When I look at the server logs, I see one of two messages:
2012-03-26 20:28:49 I msg:[SRC 127.0.0.1:49298 sid=1] SHOUTcast 1 source connection.
2012-03-26 20:28:49 E msg:[SRC 127.0.0.1:49298 sid=1] connection rejected. Bad icy header string [icy-name:]
2012-03-26 20:29:23 I msg:[SRC 127.0.0.1:49299 sid=1] SHOUTcast 1 source connection.
2012-03-26 20:29:23 E msg:[SRC 127.0.0.1:49299 sid=1] connection denied. Bad password.

The first one I get when I try to set the type to 'Shoutcast'.

The second one is when I set the type to Icecast 1.

I have tried admin, source and blank for the login, and I have verified that the password is the same in Mixxx and in the Shoutcast config file.

I did find a version 1.9 of Shoutcast, and Mixxx connected fine to that version.

[RJ Skerry-Ryan (rryan)]

This isn't possible until libshout supports it -- and libshout says they won't support it.

[Ron Laws (ron-laws86)]

This issue still persists for me on 1.11.0 on Mac OSX, i've got other broadcasting solutions (including BuTT that seem to connect to shoutcast 2 fine using the legacy protocol for V1, yet Mixxx seems incapable of doing this?

the log file in Shotucast says the issue is "Bad icy-header icy-name]" whih suggests the string being sent is incorect, from what i can gather with a quick google search on the winamp forums. the suggestion for one program causing this was to specify a custom header in the DSP (but this is not winamp) so is libshout won't be updated by the lazy developers maintaining it (or not) then perhaps a lateral solution is the way forward?

[Ron Laws (ron-laws86)]

BuTT is able to connect to Shoutcast 2 using the old/legacy v1 source connection, so this has to be a bug in the Mixxx implementation, since SC2 was designed to be somewhat compatible with v1/legacy sources

With the removal of the ia32 libs for 64bit Linux servers, and shoutcast v1 not being available in 64bit, it's now a rapidly decreasing matter of time before it literally becomes impossible to provide v1 shoutcast servers as admins/users are forced to use Version 2 for 64bit host systems

[Ron Laws (ron-laws86)]

Mixxx can broadcast to Shoutcast 2 using the legacy/v1 source connection compatibility built in to shoutcast 2, However, if you do not fill out all the required fields, shoutcast 2 will reject the source connection as it is more strict than its predecessor. I was able to get about the bad header string icy-name by actually specifying a Stream title.

a fix for this would be to change the config pane so that it either marks this as a required field, or a fallback is provided if left blank (such as sending NULL or a blank space)

[RJ Skerry-Ryan (rryan)]

Thanks Ron -- we will look at this.

[RJ Skerry-Ryan (rryan)]

But I think these are two separate issues -- connecting to shoutcastv2 servers with the v1 protocol and connecting to v2 servers with the v2 protocol.

The former is a bug -- the latter probably will never happen due to libshout.

[Daniel Schürmann (daschuer)]

Here some details about Shoutcast 2:
http://wiki.winamp.com/wiki/SHOUTcast_2_%28Ultravox_2.1%29_Protocol_Details

[RJ Skerry-Ryan (rryan)]

To follow up, Mixxx works with Shoutcast 2 using the V1 protocol if you provide a stream name. If you don't provide a stream name, Shoutcast 2 rejects the connection (where Shoutcast 1 would accept this case).

We should probably fill out Stream Name with something by default to help users avoid this.

[Ron Laws (ron-laws86)]

2 years later... I figured this out a while ago actually!

On 4 Dec 2016 17:19, "RJ Ryan" <email address hidden> wrote:

> To follow up, Mixxx works with Shoutcast 2 using the V1 protocol if you
> provide a stream name. If you don't provide a stream name, Shoutcast 2
> rejects the connection (where Shoutcast 1 would accept this case).
>
> We should probably fill out Stream Name with something by default to
> help users avoid this.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1003403
>
> Title:
> Support Shoutcast2
>
> Status in Mixxx:
> Triaged
>
> Bug description:
> I am running Windows 7 64 bit.
>
> I have Mixxx 1.10.0 installed, and it plays music fine.
>
> I have Shoutcast DNAS (v.2.0.0.29) installed on the same system and it
> 'appears' to be working (no error messages when I start it up at
> least).
>
> I have gone to Preferences->Live Broadcasting, and think I've got
> everything set up OK.
>
> When I try to Enable Live Broadcasting, I get an error message from
> Mixxx that it failed to connect to the server.
>
> When I look at the server logs, I see one of two messages:
> 2012-03-26 20:28:49 I msg:[SRC 127.0.0.1:49298 sid=1] SHOUTcast
> 1 source connection.
> 2012-03-26 20:28:49 E msg:[SRC 127.0.0.1:49298 sid=1]
> connection rejected. Bad icy header string [icy-name:]
> 2012-03-26 20:29:23 I msg:[SRC 127.0.0.1:49299 sid=1] SHOUTcast
> 1 source connection.
> 2012-03-26 20:29:23 E msg:[SRC 127.0.0.1:49299 sid=1]
> connection denied. Bad password.
>
> The first one I get when I try to set the type to 'Shoutcast'.
>
> The second one is when I set the type to Icecast 1.
>
> I have tried admin, source and blank for the login, and I have
> verified that the password is the same in Mixxx and in the Shoutcast
> config file.
>
> I did find a version 1.9 of Shoutcast, and Mixxx connected fine to
> that version.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1003403/+subscriptions
>

[Frotus Green (frotus)]

In response to:
@RJ Skerry-Ryan (rryan)
" The former is a bug -- the latter probably will never happen due to libshout."

Is this still the case? license issue or something?
Could you add support for broadcasting plug-ins and then a user/3rd party could make a shoutcast v2 plug-in to avoid license issues?

I would love to use Mixxx to send Cover Art and Next Track info to my Shoutcast v2 server!

Thanks for your time in responding.
- Frotus

[Be (be.ing)]

Given our recent difficulties working with the libshout maintainers, I think we'd be more likely to switch to an alternative library or write our own than add a new feature to libshout.

[Daniel Schürmann (daschuer)]

We are close to the plug-in situation. We have a dedicated broadcasting output for the sound and a pending PR that provides the metadata. We "just" need to tie these lose ends together.

Do you know a Shoutcast V2 solution that might pick up the data from Mixxx?

@Fractus, do you have interest to help here?

The other option would be to contribute the Shoutcast v2 changes to IDJC. We have recently switched to the IDJC fork of Shoutcast, because it allows us to broadcast with AAC-HE.

[Ron Laws (ron-laws86)]

Shoutcast2 server supports legacy v1 connections

On Tue, 16 Mar 2021, 01:24 Daniel Schürmann, <email address hidden>
wrote:

> We are close to the plug-in situation. We have a dedicated broadcasting
> output for the sound and a pending PR that provides the metadata. We
> "just" need to tie these lose ends together.
>
> Do you know a Shoutcast V2 solution that might pick up the data from
> Mixxx?
>
> @Fractus, do you have interest to help here?
>
> The other option would be to contribute the Shoutcast v2 changes to
> IDJC. We have recently switched to the IDJC fork of Shoutcast, because
> it allows us to broadcast with AAC-HE.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1003403
>
> Title:
> Support Shoutcast2
>
> Status in Mixxx:
> Triaged
>
> Bug description:
> I am running Windows 7 64 bit.
>
> I have Mixxx 1.10.0 installed, and it plays music fine.
>
> I have Shoutcast DNAS (v.2.0.0.29) installed on the same system and it
> 'appears' to be working (no error messages when I start it up at
> least).
>
> I have gone to Preferences->Live Broadcasting, and think I've got
> everything set up OK.
>
> When I try to Enable Live Broadcasting, I get an error message from
> Mixxx that it failed to connect to the server.
>
> When I look at the server logs, I see one of two messages:
> 2012-03-26 20:28:49 I msg:[SRC 127.0.0.1:49298 sid=1] SHOUTcast
> 1 source connection.
> 2012-03-26 20:28:49 E msg:[SRC 127.0.0.1:49298 sid=1]
> connection rejected. Bad icy header string [icy-name:]
> 2012-03-26 20:29:23 I msg:[SRC 127.0.0.1:49299 sid=1] SHOUTcast
> 1 source connection.
> 2012-03-26 20:29:23 E msg:[SRC 127.0.0.1:49299 sid=1]
> connection denied. Bad password.
>
> The first one I get when I try to set the type to 'Shoutcast'.
>
> The second one is when I set the type to Icecast 1.
>
> I have tried admin, source and blank for the login, and I have
> verified that the password is the same in Mixxx and in the Shoutcast
> config file.
>
> I did find a version 1.9 of Shoutcast, and Mixxx connected fine to
> that version.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1003403/+subscriptions
>

[Frotus Green (frotus)]

Yes, it does. That doesn't help you get Cover Art or the Next Playing Track to the server, however.

> Shoutcast2 server supports legacy v1 connections

[Frotus Green (frotus)]

IDJC is using a libshout fork called libshout-IDJC. (from what I found from their site)

So in the end, I think you end up adding support to libshout, which it sounded like no one wants to do because of a bad mojo between projects?

A Shoutcast middle tier that scrapes/captures audio from the audio device and streams it to Shoutcast does exist (like BUTT), but they are all v1 and do not support things like Next Playing or Cover Art, due to the nature of how they are working/hacking the experience by capturing from the audio device with not connection back to the Media Player directly. A library would need to be included into Mixxx/integrated into Mixxx to see what is in the next Deck up and send as Next Track, as well as see what the Current Cover Art is and send that to the v2 server.

I have this working using WinAmp w/ a Shoutcast DSP Plugin (it is a .DLL so not easy to inspect quickly for me) to a Shoutcast v2 server on an Azure VM. WinAmp isn't really designed to DJ and is more of a fallback as a cheap Auto-DJ system, so want to get Mixxx going so when I switch to live DJ mode, the player doesn't downgrade to no Cover Art and no Next Track listing.

> Do you know a Shoutcast V2 solution that might pick up the data from Mixxx?

> @Fractus, do you have interest to help here?

> The other option would be to contribute the Shoutcast v2 changes to IDJC. We have recently switched to the > IDJC fork of Shoutcast, because it allows us to broadcast with AAC-HE.

[Daniel Schürmann (daschuer)]

Thank you for investigation.

The reason why AAC encoding and shoutcast 2 is not part of libshout is IMHO almost the same. The maintainer have no interests for being an advocate for proprietary software solutions. Icecast-libshout (the full name) is basically the application frontend to their foss icecast server.
This is reasonable from their point of view.

This view is slightly different here when it comes to missing features in Mixxx and helping users to getting things done.

> I have this working using WinAmp w/ a Shoutcast DSP Plugin (it is a .DLL so not easy to inspect quickly for me) to a Shoutcast v2 server on an Azure VM.

Here we have the issue that the implemented ShotcastAPI inclusive there documentation is not freely available. https://shoutcast.com/Legal/LicenseAPI I don't think these restrictions suite to Mixxx.

So the best solution would be based on freely available information. If one think shoutcast 2 interface is important enough to spend his spare time on it, I am happy to integrate the work. I am sure many broadcasting users will welcome that as well. It does not matter if this integrates with our fork of libshout-idjc in the lib folder or any other solution.

Here is a link to the original documents from 2004 most likely the referenced patents are beyond there time limits: https://github.com/savonet/liquidsoap/issues/389

Here is a GPL 3 Java implementation. https://github.com/DSheirer/sdrtrunk

[Frotus Green (frotus)]

Thanks, it is starting to become clear now. Icecast doesn't appear to support Cover Art on any version. So why make Shoutcast a better option with their own library? LOL
Interesting situation, at least Real Audio isn't the defacto anymore :)

I think the main reason there is a lack of momentum in this space for Cover Art, most DJs are playing music that is mainstream and their players I have seen for larger stations pull the cover art from iTunes, etc.
Someone created this work around back before Shoutcast v2 had Cover Art in the stream, etc. So most people are using players with lots of fancy logic on finding cover art from the internet, rather than just getting it from the server, which got it from the MP3 player, which is way more efficient in my opinion and less error prone.

It was actually a little tricky to get the player to show cover art from the Shoutcast server. Even the Shoutcast Wiki doesn't mention the endpoint for Cover Art, but lists all the other endpoints for playing, playnext, etc. Someone else figured it out and posted the URL on a forum so I was unblocked.

Thanks again for helping me rationalize why SC v2 support w/ cover art is hard to find. Mixxx is an awesome product that I recently discovered. I will help out as much as I am capable.

[Be (be.ing)]

> It does not matter if this integrates with our fork of libshout-idjc in the lib folder or any other solution.

I agree. Whichever approach seems better to whoever works on implementing this would be okay IMO.

[Frotus Green (frotus)]

After much google and github searching with code reviews, only a couple entities have done this:

1) NullSoft - DSP plugin for WinAmp, their own product, .DLL
2) Bass.NET - .NET SDK that has functions for Send_Art, Send_NextTrack, etc.
BASS.NET is free for non-commercial use. If you are a non-commercial entity (eg. an individual) and you are not charging for your product, and the product has no other commercial purpose, then you can use BASS.NET in it for free*. Otherwise, you have to purchase a BASS license

Other solutions fall into 1 of 3 categories:
1) Using Bass.NET API/SDK (2 or 3 solutions) if they have full v2 support
2) Using libshout and only provide v1 features with v2 forward compatibility
3) Implemented their own code similar to libshout, using Go, Python or other languages

So unfortunately, someone needs to add code to handle the new Message Class Hex values without another FULL code implementation as a reference.

(from: http://wiki.shoutcast.com/wiki/SHOUTcast_2_(Ultravox_2.1)_Protocol_Details)
Message Class – 0x3 or 0x4
 Message Type - <metadata type>

0x3 Cacheable Metadata
0x3 0x000 Content Info Metadata (unused)
0x3 0x001 Url Metadata (unused)
0x3 0x901 XML Metadata (Aol Radio format)
0x3 0x902 XML Metadata (SHOUTcast 2.0 format)

0x4 Cacheable Binary Metadata (reserved)
0x4 0x0xx Station logo (see 'Image Notes' for xx details)
0x4 0x1xx Album art (see 'Image Notes' for xx details)
When these are received, the xx of the type is used to specify the image mime type where:
00 image/jpeg
01 image/png
02 image/bmp
03 image/gif

I've written games, mobile apps and such, not sure I am qualified for that. :)

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6476