2

We're trying to serve MP3 files from web1.cowbird.com. Most of the time everything works fine. However, sometimes there's a file that the browser is unable to play, and I have no idea why. Here is an example: http://web1.cowbird.com/items/stories/2012/11/04/05/18/47222/1_5095f977b4f532.99916135-original.mp3

If you wget or curl the file, it works fine. But trying to pull it up in Chrome or Firefox results in a strange set of errors where for some reason the browser isn't downloading the entire file and is therefore unable to play it. For some reason the browser appears to get a 200 result with the first request, then makes another request with a Range:bytes=0- header. The response headers look right, but not enough bytes are being transferred.

I've been looking all over trying to understand if it has to do with byte range requests and have tried various apache settings with no luck. Happy to provide any additional information. Thanks!

Dave
  • 141
  • 4
  • Are there any relevant messages in your logs? – user9517 Jan 18 '14 at 20:26
  • were you relying on mod_mime_magic and these files have a slightly different header? Was the content-type on the wire wrong for them? – covener Jan 18 '14 at 20:58
  • content-type was correct, and I'm not using mod_mime_magic. There were no relevant messages in the logs, other than the 206 code in the access log. I'm still working through this, as it appears lame doesn't work on all of the bad files, for example this one: http://web1.cowbird.com/items/stories/2012/03/22/10/56/15271/9b5ce75faa96ae2347a7d621ee2a1a2402e1257c9a488f6bd31df0c6d502533d-original.mp3 – Dave Jan 18 '14 at 21:12

1 Answers1

2

Ok, so it looks like it's a problem with the MP3 file, despite the fact that it can be downloaded and played on my linux desktop. The "file" command reveals this:

working mp3: Audio file with ID3 version 2.3.0, contains: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo

non-working mp3: Audio file with ID3 version 2.3.0, contains:

This led me to this site: https://code.google.com/p/chromium/issues/detail?id=268892

Which speaks to an mp3 header problem, although it's not the exact same as ffmpeg doesn't report the same error. However, running lame on the file fixes the issue, and it's now working. I used this command: lame -b 192 -h

Now that http request works.

EDIT: Unfortunately that hasn't solved the problem entirely as lame is failing for some of the files, such as this one: http://web1.cowbird.com/items/stories/2012/03/22/10/56/15271/9b5ce75faa96ae2347a7d621ee2a1a2402e1257c9a488f6bd31df0c6d502533d-original.mp3

Dave
  • 141
  • 4