Bugzilla – Bug 6266
SqueezeCenter does not download audio files to iPod Touch or iPhone
Last modified: 2009-07-31 10:15:24 UTC
SlimServer/SqueezeCenter is not able to stream to iPod touch or iPhone devices. Reason: SlimServer does not support byte range requests which are needed by iPod touch or iPhone to accept a MP3 stream.
Please do not preset targets. resetting product/component/version fields to fit with initial comment.
Squeezecenter support for streaming to iPhone/iTouch would problably make many Apple users very happy. From what I've read slimserver needs to be able support http byte range requests.
Range request support added in 7.1 change 21902.
Created attachment 3625 [details] Log file from iPhone3G I suppose the intention with this bug report was to allow stream.mp3 to work with iPod Touch and iPhone devices ? In that case it doesn't work, at least not in my setup. Here is the log file from an iPhone 3G with the 2.0 firmware.
Created attachment 3626 [details] Log file from iPod Touch 1.1.4 And here is a log file from an iPod Touch with 1.1.4 firmware which also doesn't work. I'm not sure how to re-open the bug report, maybe this is only possible for administrators and the submitter ?
Originally, this bug was meant about stream.mp3. However, iPhone can NOT play streams so there is nothing SqueezeCenter can do about that. But what SC CAN do is support byte range requests so that you can at least access files (MP3, AAC) on the server. With a skin you can build a playlist for that and have a "quasi-stream" like flytunes. It's a workaround and will not help those with flac but it's a start.
Sorry for the confusion, the direct download links works in both iPod Touch and iPhone3G after change 21902. stream.mp3 still doesn't work, but as Joerg says this is probably due to limitations in the iPod/iPhone software.
Yeah this bug is very confusing because of the use of the word 'stream'. I'll fix the title. BTW, it would be possible but a bit more effort to support transcoding on download URLs, i.e. http://server:9000/music/1/download.mp3?bitrate=192 (transcode whatever track 1 is to 192k mp3). Part of the issue with stream.mp3 (with the Tuner app) may be that we don't send a constant bitrate stream. The silence sent when you connect is at a fixed bitrate but if you start playing music with a bitrate lower than the bitrate limit it will not transcode the file, and so you can get other bitrates in the stream.
(In reply to comment #8) > BTW, it would be possible but a bit more effort to support transcoding on > download URLs, i.e. http://server:9000/music/1/download.mp3?bitrate=192 > (transcode whatever track 1 is to 192k mp3). > That would be great, you probably don't want to download high bitrate music to iPhone/iPod due to bandwidth limitations and you definitely don't want to stream FLAC.
I created a new enhancement, bug 8808.
Andy, I'm sometimes seeing some random stuttering while playing back files on my iPod touch, typically towards the end of a file (so not fully random). All iPeng is doing to playback songs is handing them over to Quicktime for playback. QT indicates that it pre-loads about four minutes of it on my 192kbps files while playing back and then loads the rest when getting close to the end. This is where the stuttering starts. Doesn't happen on files that get loaded all at once. I wonder if there may be some problem with the byte range access (like it get's a bit too much or too little data, like a wrong range border or something). It's pretty well reproducable, yet I have no idea how to debug this, is there a setting to get a log about the streaming access?
You can get a log by enabling network.http debug. When I was testing, it always loaded the entire track quickly, although I never tested with a really long track or anything like that.
Created attachment 3645 [details] demo file - VBR, gives problems in QT on iPhone
The only problems I noticed with VBR was that QT didn't detect the length properly using the Xing header. But other than that it played OK. Will give your test track a try.
Took ages to upload the file and the second one failes, so this is probably a bit outdated: OK, seems to be something else: seems to depend on the file. The issue is: QuickTime expects the wrong file size (it expects the file to be longer than it actually is, like 5:30 instead of 4:20). I have files for which this happens and others for which it doesn't. Now if it's close to the end of the file with the wrong size it seems to try to load more data but doesn't get it (understandably). Don't know if something is wrong with my files. I'll attach a working and a non-working example. Could be that the non-working files are variable bitrate files. So it's probably a Quicktime limitation rather than a server limitation. Or does the server do some own calculation on file sizes and things based on bitrates?
Do you see an endless series of requests coming from the ipod? That would indicate a bug in the range code.
Actually, yes. But not with the file I uploaded. Will upload another one tonight, my connection here is too slow. I'll attach some lines of log file...
Created attachment 3646 [details] range requests log file
Yeah that looks like a range issue. :(
Created attachment 3647 [details] demo file VBR, this is the one I did the log file with BTW, this is not an academic issue about some shatters in the sound. I found this endless loop drains power like hell. Playing back an album full of these tracks gave me only around 1.5h of playback time while I otherwise expect at least 4-6!
Of course, it also murders the server with all those little requests. :) I'll take a look ASAP.
Hmm, with this file the iphone makes only the usual 3 requests: <no range> Range: bytes=0-1 Range: bytes=0-9152511 It even seems to get the progress bar almost correct, showing a total of 6:23 for a 6:13 file. File plays perfectly fine.
Which server version? I was running tonight's 7.1 Will try with today's 7.2 later, but my iPod is currently running against that one and shows a bit different behavior: I get more "empty" progress bars but power consumption is pretty good, so probably less range issues. But that was the file I did the log with.
7.1 trunk, this should work the same in 7.1 or higher.
How did you test the playback? With iPeng or by addressing it manually or through songinfo? Maybe it acts differently whether it's loaded through the Quicktime plugin or directly. I will do some more experiments but right now my only 2.0 iPod at hand does endurance testing for the playback feature. It's running for an hour now and the battery bar has just lost the first pixel so it will probably be late tonight or tomorrow morning.
I manually loaded http://server:9000/music/1/download, I didn't test through iPeng.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC