Yes, that is due to the fact that you are trying to ask Steamcast to relay /live.mp3 on /live.mp3 and creating an infinite loop.

Change this line

...
SourceMount3=/listen.mp3
SourceRelay1=play.blunt.audio:8000/live.mp3
SourcePublicRelays=yes


to this


...
SourceMount3=/listen.mp3 ...

I will put it on the list to brainstorm. Thanks for the suggestion and thanks for using Radio Toolbox.

Are you wanting it to just display an image or do you want detailed info sent by script and generate the map say in a google api map? Either way I would have to think how best to do it so it isn't a pain for you to implement.

MPD can know though, ID3 is the same tag, they are just seeing the two different versions of the same spec. They need to just read version 2 and ignore 1.

Ugh, lazy developers.

If they refuse to fix, which I think is crazy, then it is on you the user to mitigate the bug.

I would definitely report this to your source authors, this is definitely incorrect behavior. If they have any questions you can send them my way.

That is probably what is happening then.

As an experiment remove the ID3v1 tag from a test file and send it through MPD and see if the duplicating meta entries occur for that file. If it does not then this is most definitely a bug in MPD.

What MPD should be doing is ignoring ID3v1 tags if it sees ...

Well what I'm curious about is whether they see the two ID3 tags as distinct or the same. Check your mp3 files for both versions. Most tagging and mp3 players will treat them as one tag even though within the file they are in 2 different locations. ID3v1.1 is at the end of the file and ID3v2 is at ...

You might consider cleaning up the tags in the file then, Steamcast is beholden to the source as to the legitimate track separation points. I would imagine that this is implemented in MPD this way because multiple tracks could be in a single file. If they are doing this in MP3 files at ID32 and ID31 ...

Yea no problem, set me up as an admin or mount manager and PM the details and I will try it here.

Hmm, well this is the issue

file_get_contents(http://play.futureassassin.com:8000/admin/status.json?src=%2Fauto.mp3): failed to open stream: Connection timed out in /home/fa/domains/futureassassin.com/public_html/steamcaststream.php on line 88

Basically what matters here is "Connection timed out ...

Has play. been changed or modified from a wildcard dns entry recently? Try just putting the IP address directly and see if that resolves it.

Awesome, let us know if you run into any problems, we have spent a lot of time trying to shore up some buggy stuff and make Steamcast more accessible to other Linux distributions.

Looking at your error log it appears you have it configured to pull from:

http://ice.futureassassin.com:8000/

Which according to my quick check doesn't exist. You will need to adjust the script to pull from play.futureassassin.com:8000

What version of Windows are you running Radio Toolbox on?

Well being unfamiliar with the streaming solutions you can really choose any of the options. Today there is very little to differentiate them and quite honestly with what you want to do with it, it doesn't seem that any of them or better than the other. That said, support is a factor to consider ...