-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Shoutcast2 #6476
Comments
Commented by: rryan This isn't possible until libshout supports it -- and libshout says they won't support it. |
Commented by: 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? |
Commented by: 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 |
Commented by: 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) |
Commented by: rryan Thanks Ron -- we will look at this. |
Commented by: 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. |
Commented by: daschuer Here some details about Shoutcast 2: |
Commented by: 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. |
Commented by: ron-laws86 2 years later... I figured this out a while ago actually! On 4 Dec 2016 17:19, "RJ Ryan" wrote:
|
Commented by: frotus In response to: Is this still the case? license issue or something? 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.
|
Commented by: 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. |
Commented by: 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. |
Commented by: ron-laws86 Shoutcast2 server supports legacy v1 connections
|
Commented by: frotus Yes, it does. That doesn't help you get Cover Art or the Next Playing Track to the server, however.
|
Commented by: 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.
|
Commented by: 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 view is slightly different here when it comes to missing features in Mixxx and helping users to getting things done.
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: savonet/liquidsoap#389 Here is a GPL 3 Java implementation. https://github.com/DSheirer/sdrtrunk |
Commented by: 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 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. 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. |
Commented by: Be-ing
I agree. Whichever approach seems better to whoever works on implementing this would be okay IMO. |
Commented by: frotus After much google and github searching with code reviews, only a couple entities have done this:
Other solutions fall into 1 of 3 categories:
So unfortunately, someone needs to add code to handle the new Message Class Hex values without another FULL code implementation as a reference.
0x4 Cacheable Binary Metadata (reserved) I've written games, mobile apps and such, not sure I am qualified for that. :) |
Reported by: nick-vrtis
Date: 2012-05-23T12:46:30Z
Status: Triaged
Importance: Wishlist
Launchpad Issue: lp1003403
Tags: broadcast
Attachments: [Screenshot of Mixxx streaming to a Shoutcast2 sevrer (version 2.2.2.123 x64/Posix) with the icy-name (stream name) field set.](https://bugs.launchpad.net/bugs/1003403/+attachment/4204820/+files/Screenshot of Mixxx streaming to a Shoutcast2 sevrer (version 2.2.2.123 x64/Posix) with the icy-name (stream name) field set.)
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.
The text was updated successfully, but these errors were encountered: