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

audioiossafari

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?

Best Answer

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.

Related Question