Bugzilla – Bug 249
http://server:9000/stream.mp3 allows client to buffer mp3 from the 'future'
Last modified: 2014-08-06 09:47:22 UTC
When streaming mp3 files using the http interface to some programs/devices (Netgem digital TV adapter, windows media player) the program downloads the stream into the future, and continues to download at the maximum speed the server/connection will allow until the entire playlist has streamed. This means that the if a change in the web interface is made, for example pause, is made then it will not take place until a long time later. Fix: limit 'advanced' buffering by a user definable amount?
Hi John, Most MP3 streaming clients have an adjustable buffer on the incoming side. The SlimServer doesn't do any rate control from the source, this is best done by the client, depending on its requirements.
We could add an option for some outgoing streams to be rate controlled.
This is a little annoying. A friend of mine who recently started using Slimserver to stream music to himself at work noticed this and I checked it out. I got about 155 seconds of latency streaming from 6.3.0 to WMP10 on a different system.
I'm coming up against a related issue when trying to stream to an iPod Touch. Because the data rate is unrestricted, it doesn't cope with the amount of audio and metadata arriving and crashes. I understand that the authors of the streaming apps could rewrite their code to restrict the speed, but these apps play other mp3 streams off the Internet fine, so they would say that the 'SqueezeCenter mp3 stream' is non-standard in the way it is delivered. An option to restrict the delivery rate of the mp3 stream, and turn metadata on or off, would be helpful to alleviate this situation.
A bit more info: I am using SC7.21 or 7.3 on Mac OS X, streaming via the http interface to an iPod Touch using the 'CastCatcher' software (www.return7.com), which works perfectly with online radio streams. When I set an album (50 mins) to play over my home network on the iPod, the SC interface shows all *ten* tracks playing and then the player switching to stopped *before* the first track has finished playing. After a short period of time the iPod stream player would crash, even though it will stream for significant periods of time without problems on 'normal' internet radio streams. A second (but related) problem was that the high data rate was also pushing through way more metadata than the iPod application could cope with, causing it to crash. The author of CastCatcher has released a hack which stops metadata being requested for streams ending in ":9000/stream.mp3" which isn't ideal because it means the iPod doesn't show the current track. Also, although it made the playback work for a bit longer, it still crashed a little while after SC had finished pushing out the music data. So we have a situation where a client (CastCatcher on iPod Touch) plays all mp3 streams apart from the SC http stream without fault, but is unable to play the SC stream. The same or similar behaviours are all seen in other stream players on the iPod - "fstream" and "nullRiver Tuner Internet Radio" for example - they can not cope with the high data rate pushing through audio data and metadata at the speed that SC pushes it out. Dean - you mentioned that an option could be added for some outgoing streams to be rate-controlled. How hard would this be? I ask because I think if we could set the maximum stream data rate to a particular rate (or to the same as the music bitrate selected in the http player audio options) it would solve this problem and would not negatively impact any other players. It would also lead to the now playing information in SC matching up with the music being played on all mp3 stream players (which it doesn't on any player at the moment), because the SC would not get ahead of itself. I would suggest the following option on the Audio page of any http player settings: ============================================================= 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 don't know enough about whether the metadata forms part of the audio stream or not - it just occured to me that if you have, say 128kbps of audio data and 1kbps of metadata, then throttling the stream data rate to 128kbps would mean the audio would not keep up with real time. If the metadata is included in the mp3 bitrate total then this isn't an issue. Just a thought.
I really like my slimbox when I'm home. I'm really hoping the Ipeng controller for the iphone turns into a player by using stream.mp3 so it would be nice for SC to support a better streaming protocol. I really don't want to use Itunes.
Can we change the Version on this bug to "all" or 7.x or older?
This bug is still not resolved. It still exists in the latest Squeezebox Server release. Given that Dean suggested that it would be possible to restrict the data rate on stream.mp3, could we not see this change implemented? It would open up *correct* SBServer mp3 streaming to two of the most widespread mp3 stream players: Windows Media Player and the iPhone/iPod Touch, as well as others.
Dean doesn't work here any more :)
Now STRICTLY speaking that doesn't mean he can't fix the bug :)
I see this bug has recently celebrated its sixth birthday! Can we change the version to "All" instead of "5.x or older"? It still exists in the latest builds... I can't imagine it's *that* hard to restrict the data rate on an outgoing mp3 stream.
Unassigned bugs cannot have a priority.
This isn't a server bug but the way most streaming clients work: they buffer as much as they can. It's a client side issue. As nowadays there are SB compatible clients available for many platforms I'm going to close this request.