Bugzilla – Bug 11332
Allow configuration parameters to mp3 stream (i.e. http://server:9000/stream.mp3?maxbitrate=96)
Last modified: 2009-03-12 19:32:06 UTC
Recently I enabled the internet on my phone to see what it was like and the first thing did was fire up audio app (Pocket Tunes on a Palm Treo 680) and listen to some internet radio. It worked like a charm and it was amazing to be listening to that stuff while I was walking around or in the car. Excited, I fired up http://server:9000/stream.mp3. Nothing. I twiddled with some settings, still nothing. I left the audio app and went to the web browser and opened the Squeezecenter interface. Problem is, because my phone (like many smart phones) doesn't multitask, closing the audio app meant I wasn't connected to slimserver which means there was no entry in the menu. When I got home I did it again, this time using the local wifi laptop for SqueezeCenter while the phone went over the cell network. The problem was that streaming at 320K, far too high for the available bandwidth to the phone. So I dialed it down. Success and delight! Later I tried it again. Failure. The reason? The IP addresses are dynamically assigned to the phone each time you connect, so SqueezeCenter was seeing this as a completely new player and didn't access the parameters I had changed. And now I was back to the problem of leaving the audio app. What I propose is having parameters in the stream.mp3 URL along the lines of this: http://server:9000/stream.mp3?maxbitrate=96&replaygain=none This nails it because you can get results the very first time you use it (i.e. no set-up on the server), and because you can bookmark the URL that will allow you to have multiple configurations (for instance, with an iPhone you could have one URL for low-bandwidth access over 3G and a second URL for high-bandwidth access when you're within range of your local wifi signal). A number of enhancements related to stream.mp3 have been proposed. In some cases this enhancement would encompass (and solve) those issues, and in other cases those enhancements would need to be considered while implementing this one. --Use lower bitrate limit as default for streaming client https://bugs-archive.lyrion.org/show_bug.cgi?id=3695 This would have done the trick for my phone but lacks the bookmarkability and the multi-IP flexibility (i.e. maybe I want one setting for my Treo over Edge and another setting for the wife's iPhone over 3G, and I can't just customize and save them because of the dynamic IPs) --Use name instead of IP address (since we don't use MAC) https://bugs-archive.lyrion.org/show_bug.cgi?id=801 This actually WOULD work, I like this very much. The only trouble is that it requires server-side setup, and again I have the problem where if I want to do this remotely, I may not be able to switch back and forth between the audio app and the web browser. --http://server:9000/stream.mp3 allows client to buffer mp3 from the 'future' https://bugs-archive.lyrion.org/show_bug.cgi?id=249 This lists a number of issues that would still have to be considered with this solution, specifically naming a few of the parameters that would need to be available in the URL string to help solve that issue (i.e. Stream data rate limit: [ Do not limit stream data rate ](push data out as fast as the network can manage) [ Limit to same as bitrate limit ] (push music data at the same speed as the bitrate limit) I own three pieces of Squeezebox hardware. This enhancement would help leverage my investment in the Slimdevices stack: my whole collection lives in SqueezeCenter, and while I can already play it remotely (streaming to work was originally what brought me into the Slimdevices family, and I bought hardware a few years later) the ability to play my collection remotely through a *mobile* device is getting more important. If you implemented this *AND* DLNA (https://bugs-archive.lyrion.org/show_bug.cgi?id=5091), I'd be even MORE fully leveraging my investment in Slimdevices!
Mike, bug 27 already covers some of your request and was implemented in SqueezeCenter some time ago. The format is http://slimserver:9000/stream.mp3?bitrate=128 for 128 kbps for example. As far as replaygain goes this is only handled in the player and is not applicable to stream.mp3. For the other bugs you mentioned I suggest voting for them if you have not done so already. *** This bug has been marked as a duplicate of bug 27 ***
I guess this should be considered a documentation bug then: being able to specify the bitrate in the URL offers at least a partial solution to all three of the bugs I mentioned, yet none of them or their discussions mention it. Particularly https://bugs-archive.lyrion.org/show_bug.cgi?id=3695...it could be argued that there's no need to have a default of any kind since you can specify what you want in the URL itself. At any rate, thanks for pointing this out, and I will being using this feature immediately.