I wasn't really planning on asking this quesiton here, but since somebody needs to make use of this forum, I thought I'd be the first to post an on-topic off-topic post.

I'm having an issue with the mp3 server app I'm writing for myself (not run on the empeg, but rather on my Win2K/IIS server and using the empeg csv export and fid backups). I got everything mostly working, but when I use the header Content-Length when sending a mp3 file, PHP (which is what the app is writen in) throws me a fatal error about the script timeout after 30 seconds.

I find that a bit wacky, since it always sends the entire mp3 regardless of song length, and then appends the text of the error message to the end of the data. I only noticed this when trying to figure out why the ID3 tags were lost during download. Turns out that they weren't really lost, but the error message text at the end of the file hosed it up. The file still played fine, though..which is why I didn't notice it at first.

Sooo...I thought maybe I was just sending a bad value for content-length, but I can't imagine that causing this type of behavior. I tried using both the length field from the csv export, and PHP's filesize funtion on the fid when reading the data to send. The script throws the fatal error in either case.

I disabled that particular header and everything works fine, ID3 tags and all. I was thinking it would be better if the browser knew how much data to expect, no? At least IE was telling me x of x mb with the header there, which I don't get now, but I get a non-hosed mp3 file.

Any suggestions? Does the content-length header matter that much to my web browser, or Winamp (when streaming instead of straight download)? Should I care?

Sorry for being on-topic...
_________________________
- Chris Orig. Empeg Queue position 2