Why does streaming audio in Mobile Safari sometimes not have a scrubber bar?

Solution 1:

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.

Solution 2:

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.