Zwykle, jeśli kliknę link do pliku mp3 w przeglądarce Safari na telefonie iPhone, będzie on wyglądał mniej więcej tak:
Ale czasami wygląda to tak, bez paska szorującego:
Co to wskazuje na różnicę między plikami? Czy jest to związane z problemem z konfiguracją serwera?
Odpowiedzi:
Różnica powinna być plikiem statycznym o zdefiniowanej długości zawartości w porównaniu ze strumieniem shoutcast lub serwerem, który nie obsługiwał długości zawartości pliku.
Jeśli odtwarzacz nie wie, jak duży jest plik, nie może odzyskać końca w celu zebrania metadanych (w szczególności czasu trwania utworu) i przedstawienia skrubera do wyszukiwania.
[edytuj]
Wyjście nagłówka cURL:
$ 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
W drugim pliku (przez flex) zauważam brak „zakresów akceptacji” i „połączenia” typu „utrzymywanie przy życiu”.
To mi mówi;
(1) że Safari (/ QuickTime?) Prawdopodobnie nie wyda żądania zakresu bajtów dla końca pliku w celu odczytania danych ID3, lub;
(2) Nie ma skrubera, ponieważ „Connection: keep-alive” oznacza, że nowe dane mogą zejść przez potok, więc pozostaw gniazdo otwarte, aby je odebrać w pewnym momencie.
Oto odpowiedź dostarczona przez wsparcie Rackspace Cloud Sites:
Nasze serwery nie mogą przesyłać strumieniowo plików multimedialnych, więc otwarcie pliku multimedialnego, takiego jak mp3, byłoby odtwarzane przy użyciu metody zwanej progresywnym pobieraniem w przeglądarce lub urządzeniu. W poniższym artykule opisano pobieranie progresywne: http://en.wikipedia.org/wiki/Progressive_download
Zasadniczo odtwarzacz multimedialny pobierze plik od początku do końca i umożliwi odtwarzanie części pobranego pliku. Urządzenia z iOS, podobnie jak wiele innych urządzeń mobilnych, mają ograniczoną pamięć, więc przestaną pobierać plik po zapełnieniu wewnętrznego bufora, aby mógł zaoszczędzić tyle cennej pamięci RAM, jaką ma do dyspozycji. Chociaż pobieranie zostanie zatrzymane, urządzenie będzie nadal odtwarzać część pobranego do tej pory pliku multimedialnego. Gdy urządzenie zbliży się do końca pobranych danych, wysyłane jest nowe żądanie HTTP, aby wznowić pobieranie pliku multimedialnego, aby odtwarzanie było nieprzerwane. Po wznowieniu pobierania nowych danych cykl rozpoczyna się ponownie, gdy urządzenie zatrzymuje się, gdy bufor jest pełny.
W przypadku tego pliku krok wznawiania kończy się niepowodzeniem, ponieważ wznawianie pobierania pliku nie jest obsługiwane w plikach multimedialnych w naszych systemach, co widać po „Nieobsługiwanych zakresach: bajty” w nagłówkach odpowiedzi HTTP dla tego pliku :
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: HITWięcej informacji na temat „Accept-Ranges: bytes” można znaleźć w sekcji 14.5 tutaj: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Wznowienie pliku nie jest obsługiwane dla tego żądania HTTP, ponieważ to żądanie HTTP nie jest obsługiwane przez Apache, ale przez buforowane serwery Varnish w naszym klastrze Media Accelerator. Wznowienie pliku jest z natury obsługiwane przez Apache. Lista plików buforowanych w naszych systemach przez nasze serwery Varnish, a także więcej informacji na temat naszego Media Accelerator można znaleźć tutaj: http://cloudsites.rackspacecloud.com/index.php/What_is_the_Media_Accelerator_(MA)%3F
Żądania HTTP są kierowane do Media Accelerator tylko wtedy, gdy żądanie HTTP kończy się w jednym z tych rozszerzeń plików. Jeśli ciąg zapytania zostanie dodany na końcu adresu URL lub jeśli adres URL zostanie utworzony w innym rozszerzeniu pliku, wówczas żądanie HTTP jest obsługiwane przez Apache, jak widać z dwóch następujących zestawów nagłówków:
$ 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=/Aby ten plik mógł być poprawnie przesyłany strumieniowo z naszych serwerów, Media Accelerator musi zostać ominięty, ponieważ urządzenie musi użyć adresu URL, takiego jak „http://flex.ekk360.com/judas-and-pilate.mp3?1” lub zmieniając nazwę pliku i dodając niestandardowy typ MIME do swojej witryny, aby urządzenie otworzyło plik za pomocą odtwarzacza multimedialnego. Alternatywą byłoby hostowanie pliku za pośrednictwem CDN, takiego jak Cloud Files lub Amazon S3.