Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Before I start looking for a new web host, I could use some help. (long)
#1
This has been driving me batty for some time now and nobody can figure out what the problem is, so I turn to the collective minds of the forum.

I have a website which (ideally) allows clients to hear demos, etc. in real time. I also use it for uploading files for later download, but right now the problem is with the streaming audio. In fact, I just uploaded an .mp3 audiofile for this little test and I'm encountering the same problem. The file just zips right through the audio without actually playing it. If it's a longer file, the cursor moves so quickly through that it gets to the end after playing only a few seconds of audio.

The problem occurs in Firefox on both my 2.16g iMac and our 450 dual Graphite, but it plays fine in Safari on both computers. It's also screwy using Firefox on a Mini at my work. I mentioned it to my site designer and he had a similar issue, stating I checked out the demos on your site with my PC and they only worked properly in one browser. It's called SlimBrowser and it's my browser of choice because it offers many more features than IE. IE played the clips, but for some reason they seemed to play in RealPlayer instead of QuickTime. SlimBrowser played them in QuickTime. Firefox played them in QuickTime, but did what you described - played only a portion of the clip and the play head just zipped right across.

When I submitted a Help Desk ticket to my host earlier today, they responded with I'm listening to the mp3 file now ... I'm not able to duplicate this on windows OR linux - in firefox. I have no way of testing it in Internet Explorer. [snip] Sorry - can't help you any further if I can't replicate the issue. I've had 3 people here try and none have had the problem.

So it seems to be working okay for them, and as a result of course they say it's not a problem on their end. But, here's an interesting wrinkle. For the hell of it, I uploaded the earlier file in question onto my small personal web space with Comcast, and it played fine for me using Firefox, which is what led me to think it might have something to do with the host.

I'm really baffled and would appreciate any insight anyone could shed on the issue. Here's a short file just so you can check it on your browser and/or system if you wouldn't mind, to see if the same thing happens for you.

UPDATE: I just checked the link above and now the file plays more than it did prior to posting, but it still doesn't play the complete file...it runs out of timeline before the audio is finished. That seems even more bizarre. It's almost as if the speed of the computer has an effect on the speed the audio plays back. But that can't be possible...can it?
Reply
#2
First, you aren't really streaming the audio, it's just HTTP download.

I put the file up on a comcast server and gave it a try. Below are the HTTP logs from your server and from comcast:

5.7 (v621.0.99313) (2008-04-04 16:49:45)

2008-05-14 21:41:23 Tx: GET : headers={
Accept = "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5";
"Accept-Language" = "en, ja;q=0.95, fr;q=0.89, de;q=0.84, es;q=0.79, it;q=0.74, pt;q=0.68, pt-pt;q=0.63, nl;q=0.58, sv;q=0.53, nb;q=0.47, da;q=0.42, fi;q=0.37, ru;q=0.32, pl;q=0.26, zh-hans;q=0.21, zh-hant;q=0.16, ko;q=0.11";
"Cache-Control" = "max-age=0";
"User-Agent" = "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/523 (KHTML, like Gecko, Safari/523.10) OmniWeb/v621.0.99313";
}, body=(null)
2008-05-14 21:41:23 Tx: GET : headers={
Accept = "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5";
"Accept-Encoding" = "gzip, deflate";
"Accept-Language" = "en, ja;q=0.95, fr;q=0.89, de;q=0.84, es;q=0.79, it;q=0.74, pt;q=0.68, pt-pt;q=0.63, nl;q=0.58, sv;q=0.53, nb;q=0.47, da;q=0.42, fi;q=0.37, ru;q=0.32, pl;q=0.26, zh-hans;q=0.21, zh-hant;q=0.16, ko;q=0.11";
"Cache-Control" = "max-age=0";
"User-Agent" = "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/523 (KHTML, like Gecko, Safari/523.10) OmniWeb/v621.0.99313";
}, body=(null)
2008-05-14 21:41:23 Rx
2008-05-14 21:41:23 Rx Status: 200 no error
2008-05-14 21:41:23 Rx Headers:
{
"Accept-Ranges" = bytes;
Connection = "Keep-Alive";
"Content-Encoding" = gzip;
"Content-Type" = "audio/mpeg";
Date = "Thu, 15 May 2008 04:41:23 GMT";
Etag = "\"179122b-20590-33d7cd80\"";
"Keep-Alive" = "timeout=1, max=100";
"Last-Modified" = "Thu, 15 May 2008 03:07:50 GMT";
Server = "Apache/2";
"Transfer-Encoding" = Identity;
Vary = "Accept-Encoding,User-Agent";
}
2008-05-14 21:41:23 Rx has main document
2008-05-14 21:41:24 http://www.dgvo.com/MRF/stuck.mp3: Operation could not be completed. (WebKitErrorDomain error 204.)

------------

2008-05-14 21:43:35 Tx: GET : headers={
Accept = "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5";
"Accept-Language" = "en, ja;q=0.95, fr;q=0.89, de;q=0.84, es;q=0.79, it;q=0.74, pt;q=0.68, pt-pt;q=0.63, nl;q=0.58, sv;q=0.53, nb;q=0.47, da;q=0.42, fi;q=0.37, ru;q=0.32, pl;q=0.26, zh-hans;q=0.21, zh-hant;q=0.16, ko;q=0.11";
Cookie = "RMID=1813228a40; OAX=GBMiKAABUMy";
"User-Agent" = "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/523 (KHTML, like Gecko, Safari/523.10) OmniWeb/v621.0.99313";
}, body=(null)
2008-05-14 21:43:35 Tx: GET : headers={
Accept = "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5";
"Accept-Encoding" = "gzip, deflate";
"Accept-Language" = "en, ja;q=0.95, fr;q=0.89, de;q=0.84, es;q=0.79, it;q=0.74, pt;q=0.68, pt-pt;q=0.63, nl;q=0.58, sv;q=0.53, nb;q=0.47, da;q=0.42, fi;q=0.37, ru;q=0.32, pl;q=0.26, zh-hans;q=0.21, zh-hant;q=0.16, ko;q=0.11";
Cookie = "RMID=1813228a476960a0; OAX=GBMiikdpYKAABUMy";
"User-Agent" = "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/523 (KHTML, like Gecko, Safari/523.10) OmniWeb/v621.0.99313";
}, body=(null)
2008-05-14 21:43:35 Rx
2008-05-14 21:43:35 Rx Status: 200 no error
2008-05-14 21:43:35 Rx Headers:
{
"Accept-Ranges" = bytes;
Connection = "Keep-Alive";
"Content-Length" = 132496;
"Content-Type" = "audio/mpeg";
Date = "Thu, 15 May 2008 04:43:35 GMT";
Etag = "\"4fda745-20590-482bbf3f\"";
"Keep-Alive" = "timeout=5, max=30";
"Last-Modified" = "Thu, 15 May 2008 04:42:39 GMT";
Server = Apache;
}
2008-05-14 21:43:35 Rx has main document
2008-05-14 21:43:36 http://home.comcast.net/~filehost/dmf/stuck.mp3: Operation could not be completed. (WebKitErrorDomain error 204.)


I don't have much time at the moment, or I would dig and find the exact issue.

But overall, you shouldn't be relying on what plug-in the visitor has configured to play MP3 files. A pretty safe way is just to use a Flash MP3 player. That would probably solve the problem.
Reply
#3
Thanks for the reply, M A V I C. I realize it's not really streaming, but I couldn't think of another way to put it. Thanks for clarifying.

As to the specific problem, when my new site is done, it will have a Flash MP3 on it for demos. In the meantime, though, shouldn't an .mp3 file play normally no matter what the end user's browser is? I mean, it's a fairly ubiquitous audio file format and far from proprietary. And why would the same file play fine from one site but not another? I'll have to plead ignorance as to the information in the logs you provided, but I appreciate your taking the time to do so.

Until this gets ironed out, my biggest question is whether this could be any fault of my host. They've been great thus far and if I don't have to look for a new one, I'd rather not. But if this is a problem that they could rectify, but either choose not to, or don't know how, then I might have to change hosts.

Any thoughts in that regard?
Reply
#4
It sounds like your files aren't being downloaded properly by the browser. Quicktime attempts to play the partially-downloaded file and obviously fails. The browser that does download the file fully (whichever that happens to be for each user) is able to successfly play the .mp3 file as intended.

The reason that you keep getting the same behavior on multiple attempts is that you are playing a cached copy, i.e. it is attempting to use the file already downloaded instead of trying to download it again.

Instead of simply clicking on the link to the .mp3 file and trusting the browser to do the right thing, right-click (ctrl-click) and choose to download the file. Then you can see how well the file is downloaded, what size it is, and play it outside of the browser window in QuickTime or other player software directly.

My guess is that the failure could be either on your web host, your Internet connection, or somewhere on the Internet in the middle. It is likely a transient failure.


Some major Internet service providers have been taking direct action to curtail 'file sharing'. They have been modifying the traffic flowing through their network to interfere with swapping of audio and movie files. This takes the form of modifying the packets so that the file sharing software fails. You could be falling victim to this new trend as collateral damage.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)