Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Usually, if I click a link to an mp3 in Safari on the iPhone, it will look something like this:

scrubber bar

But sometimes, it looks like this, with no scrubber bar:

no scrubber bar

What does this indicate about the difference between the files? Is it related to a server configuration issue?

share|improve this question

migrated from superuser.com Mar 29 '11 at 2:20

This question came from our site for computer enthusiasts and power users.

2 Answers 2

The difference should be a static file with a defined content length, vs. a shoutcast stream or a server that did not serve a content length with a file.

If the player does not know how large a file is, it cannot retrieve the end to gather metadata (notably, song duration), and present the scrubber for seeking.

[edit]
cURL Header Output:

$ curl -I "http://demo.ekklesia360.com/judas-and-pilate.mp3"
HTTP/1.1 200 OK
Date: Tue, 29 Mar 2011 21:59:15 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Tue, 29 Mar 2011 16:25:33 GMT
ETag: "8b30001-ab4caa-49fa182643940"
Accept-Ranges: bytes
Content-Length: 11226282
Connection: close
Content-Type: audio/mpeg

$ curl -I "http://flex.ekk360.com/judas-and-pilate.mp3"
HTTP/1.1 200 OK
Server: Apache/2.2
Content-Type: audio/mpeg
Last-Modified: Tue, 29 Mar 2011 16:27:10 GMT
Content-Length: 11226282
Date: Tue, 29 Mar 2011 21:59:20 GMT
Age: 0
Connection: keep-alive
Via: 1.1 varnish 172.17.0.138

On the latter file (via flex), I notice a lack of "Accept-Ranges", and a "Connection" type of "keep-alive".

This tells me that;
(1) that Safari (/QuickTime?) likely will not issue a byte range request for the end of the file in order to read the ID3 data, or;
(2) There is no scrubber because "Connection: keep-alive" means that new data may come down the pipe, so keep the socket open to receive it at some time.

share|improve this answer
1  
In both cases it was just a static file, but they were on different servers. I checked the file in question here web-sniffer.net using iPhone Mobile Safari as the user agent, and it does report a Content-Length. –  shanebonham Mar 29 '11 at 4:54
1  
@shane From your wifi signal strength, I'd say @vxj might still be right. Does this issue happens every time for a specific file/server? Since it's big file, maybe Safari didn't have the time to fetch the length and it would rather let you play the file, instead of waiting for the information. –  Loïc Wolff Mar 29 '11 at 11:56
    
Are you at liberty to divulge the addresses of the files in each of the screenshots? –  Jason Salaz Mar 29 '11 at 16:40
    
I'm not sure which ones those were, but here are some equivalents: Everything fine: demo.ekklesia360.com/judas-and-pilate.mp3 Scrubber doesn't appear: flex.ekk360.com/judas-and-pilate.mp3 –  shanebonham Mar 29 '11 at 17:08
    
@Loïc It happens for every file I've tested on this particular platform (Rackspace Cloud Sites). On our Rackspace managed server, and other servers I have tested (Amazon S3, Dreamhost), everything is fine. –  shanebonham Mar 29 '11 at 17:14
up vote 2 down vote accepted

Here was the answer supplied by Rackspace Cloud Sites support:

Our servers cannot stream media files so opening a media file such as an mp3 would be played back using a method called progressive download within a browser or device. The following article describes progressive downloading: http://en.wikipedia.org/wiki/Progressive_download

Basically, the media player will download the file from start to finish and allows you to play the portion of the file that has downloaded. iOS devices, like many other mobile devices, are limited in memory so will stop downloading the file after its internal buffer is full so that it can conserve what precious little RAM it has available. Though the download stops, the device will continue to play the portion of the media file it has downloaded so far. Once the device gets near the end of the downloaded data a new HTTP request is sent to resume downloading of the media file so that playback is uninterrupted. Once the download of new data resumes, the cycle starts again with the device pausing when its buffer is full.

In the case of this file, the resume step is failing as file download resuming is not supported on media files within our systems as can be seen by "Accept-Ranges: bytes" not being present within the headers of the HTTP response for this file:

HTTP/1.1 200 OK Server: Apache/2.2
Content-Type: audio/mpeg
Last-Modified: Tue, 29 Mar 2011
16:27:10 GMT Content-Length: 11226282
Date: Tue, 29 Mar 2011 22:00:33 GMT
X-Varnish: 1663119465 1663112299 Age:
73 Connection: keep-alive Via: 1.1
varnish 172.17.0.138 X-Cache: HIT

More information on "Accept-Ranges: bytes" can be found in section 14.5 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

File resume is not supported for this HTTP request as this HTTP request is not being served by Apache, but via the caching Varnish servers within our Media Accelerator cluster. File resume is supported by Apache inherently. A list of files cached within our systems by our Varnish servers as well as more information on our Media Accelerator can be found here: http://cloudsites.rackspacecloud.com/index.php/What_is_the_Media_Accelerator_(MA)%3F

HTTP requests are only routed to the Media Accelerator when the HTTP request ends in one of these file extensions. If a query string is added to the end of the URL or if the URL is made to a different file extension, then the HTTP request is served by Apache as can be seen from the following two sets of headers:

$ curl -I
'http://flex.ekk360.com/judas-and-pilate.mp3?1'
HTTP/1.1 200 OK Server: Apache/2.2
Content-Type: audio/mpeg Date: Tue, 29
Mar 2011 21:41:56 GMT Accept-Ranges:
bytes Connection: Keep-Alive
Set-Cookie:
X-Mapping-hpadogcb=018693E96D995C67FDE4A82FC7761170;
path=/ Last-Modified: Tue, 29 Mar 2011
16:27:10 GMT Content-Length: 11226282

$ curl -I
'http://flex.ekk360.com/judas-and-pilate.mp_'
HTTP/1.1 404 Not Found Server:
Apache/2.2 Content-Type: text/html;
charset=iso-8859-1 Date: Tue, 29 Mar
2011 22:12:29 GMT Transfer-Encoding:
chunked Connection: Keep-Alive
Set-Cookie:
X-Mapping-hpadogcb=381D7664F27DBFFB6452A51D70DEDB28;
path=/

In order for this file to be streamed properly from our servers, the Media Accelerator must be bypassed by having the device either use a URL such as "http://flex.ekk360.com/judas-and-pilate.mp3?1" or by renaming the file and adding a custom mime type to your site so that the device opens the file with the media player. An alternative would be to host the file through a CDN such as Cloud Files or Amazon S3.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.