Would not have been possible without the guidance from these pages!

https://websavers.ca/shoutcast-vs-icecast-radio-streams

^ Told me that the Icecast source software (Ices2/Ices0.4) works with Shoutcast server software.
Just need to remember to modify the "protocol" in the Ices0.4 config from HTTP to Icy.

https://gist.github.com/lifthoofd/cd497b042af777dc02e8

^ Guided me on installing Ices0.4 so that I didn't have to stream from WinAmp on another device.

It's not as easy as you think...

After getting everything going with the music playlist running on loop with Ices0.4 and Shoutcast, I soon noticed after running htop that the Ices processes were all using 100% of each vCore they were assigned to. But why 100%? Why is there 2-4 processes instead of just one? From what I read online the CPU usage for Ices0.4 should be almost nothing, all its doing is sending an audio stream to Shoutcast running on the very same VPS. Shoutcast then sends that out to the web over port 8000. Shoutcast's CPU usage peaks at about 1.5%.

After doing some searching online, I could only find one page that mentions high CPU usage with Ices0.4, the reason being reencoding. So I check my ices.conf file and it read... <Reencode>0</Reencode> AKA, it's disabled, so reencoding the audio is not whats causing the 100% CPU. I then spent another hour modifying the small config file, looking at logs and the debug output of Ices but could not find a thing, the CPU usage was always 100%. I did notice though that it didn't seem to be slowing down the system at all.

So I started questioning what these processes were actually doing, I decided to kill PID the 100% processes only to discover that the music kept on streaming without them! So why were they there?!?!?!

At some point I found the command ps aux | grep ices which gave me a list of Ices processes and their PIDs which made killing them easier as I could just copy the PIDs from the list unlike htop which does not let me select the text! This also showed me an Ices process using 0.2%ish of the CPU, that was the process sending the stream that I need to keep alive. At this point I thought I was done, I'd killed the 100% processes and left the 0.2% process endlessly streaming my music to shoutcast, but I was wrong...

Up until this point, my "playlist" consisted of just two files, the historic WinAmp Llama .mp3 (even though I moved my source from WinAmp to Ices v0.4) and a single but hours long .mp3 that I downloaded from YouTube. Now I started adding more shorter .mp3 files only to discover these 100% processes were appearing not when I started streaming but when an .mp3 file started streaming, after every song a new 100% process would start as the next song started. I tested this with two very short .mp3 files and suddenly as it repeated the playlist swapping from .mp3 to .mp3, my VPS had tons of ices processes using up all my CPU doing who knows what, quitting ices would kill them all but that doesn't solve anything, I need my playlist running 24/7!

Eventually I realized I was naive to think this would all be easy. The ices-0.4.tar.gz that I'm using to stream my music has not been updated since 2004 and in all honesty I'm very unfamiliar with linux. It's probably a miracle that it "works" at all and definitely would not have been possible without the ancient guides on the internet and of course the great chatGPT feeding me every linux command I need to know.

So back to the problem, every time my playlist advances to the next song a new 100% ices process spawns and doesn't go away unless i kill the process manually or quit ices all together. If I do nothing it's almost like memory leak, processes would just keep on appearing forever, I'm going to call it a process leak. At this point, although I barely have any knowledge on this type of thing, I'm going to blame the process leak on the 2004 code. This program was not made for today's OS and I should not expect it to work on today's OS. Fortunately I used the last of my brainpower after troubleshooting for hours to ask chatGPT to write me a script. The script I wanted was simply to kill any Ices process that used over 80% CPU and it works perfectly, leaving behind only the low CPU 0.2% process that is actually doing the audio streaming. This script is only a workaround and runs every 60 seconds. There will still be spikes in processor usage every time an mp3 file starts streaming but at least now in under 60 seconds the process will be killed and the script will keep the process leak at bay.

Like I mentioned earlier, I don't notice any difference in performance with these 100% processes and still don't know what they're actually doing, if anything. I just don't want them there and don't want to open my VPS the next day only to see hundreds of the same ices process. If I ever do notice them causing performance issues, I will have to find a new solution. There is a newer, but still very old, version of ices0 on github but I lack the needed knowledge to get it built and compiled, the only one I could get running was the 2004 version.

Well that's about it. I've decided the mysterious 100% processes are due to old code, and chatGPT created a script that will kill them in under 60 seconds so that they don't infinitely build up. Based on that, I think the only true "fix" would be to dig into the code but I'm not a programmer.

The only other issue I've had is that when streaming a playlist, if one mp3 is 48000 Hz and the next is 44100 Hz, or vice versa, it will pause the radio on the client's end. At least that I can fix by resampling all my music to the same sample rate. I'll also point out that a 48000 Hz sample rate stream from Ices0.4 to shoutcast seems to work perfectly! Unlike WinAmp where the stream needs to be 44100 Hz for some reason.

Script that kills any Ices process over 80% cpu. Not that anyone will ever read this or need it! I used "crontab" to repeat the script every 60 seconds as advised by chatGPT.

2024/12