After my last post, I was able to make contact with someone at Justin.TV, and apparently the ad thing was a temporary glitch. Whew. Do let me know if you see it doing that again, though!
0 Responses:
Keep your eyes on the calendar, because later tonight we will be putting a very few VIP tables on sale for the Prince shows. They will include admission for six, a bottle of liquor, and a view of the stage!
13 Responses:
-
-
jwz says: No, it really doesn't. I can keep saying no, and you can keep providing no information.
-
From my perspective it doesn't work.
1.) Navigating to this page:
http://www.dnalounge.com/webcast/archive/2.) and clicking the first "8:40" link
3.) results in the error message popping up in the media player visible at the bottom of the page.I can attach a uuencoded screenshot if you like, or email something to you. I don't want to spend too much time troubleshooting for you, but yes, indeed, from a customers view there is an error message rather than the expected media playback.
-
jwz says:
Well, it works for me.
Sorry.
-
No worries.
-
-
-
-
-
It doesn't work for me, on Windows 7, with Chrome 26.0.1410.64 m. For example, when I click on one of the times for Booty, it tries to get "http://cerebrum.dnalounge.com:8001/audio/2013/04-06.mp3", with Range: bytes=0-. Looking at the headers, your server simply doesn't send anything back, not even the response headers. If I directly navigate to the mp3 in a separate window, Chrome will first request Range:bytes=45908-45908. Your server sends 1 byte back, with 206 Partial Content. Chrome will then request Range: bytes=0-, and your server never responds. Firefox on the same machine will get the mp3 fine.
-
And Chrome shows the download as being "cancelled".
-
jwz says:
Well, Safari and Firefox on OSX work fine, so absent someone very specifically proving to me otherwise, I'm going to assume that Chrome has its head up its ass.
The server definitely responds to "bytes=0-":
> GET /audio/2013/04-06.mp3 HTTP/1.1
> Range: bytes=0-
...
< HTTP/1.1 206 Partial Content
< Content-Range: bytes 0-373709845/373709845
< Content-Length: 373709846
-
Decided to play about with this one with Telnet, despite the fact that it was working for me (with Firefox(on Debian)).
Firefox (and I'm guessing Safari) sends a header;
Host:cerebrum.dnalounge.com:8001
Chrome/Chromium appears not to, adding and removing this line to a bunch of stuff pasted into Telnet appears to be the difference that breaks it.Can't remember enough of the HTTP spec to tell if this is chrome playing up or not, and frankly the fact that I'm doing this strongly implies that sleep deprivation madness has set in. Anyway, hope this helps.
-
jwz says:
That's impossible, because if Chrome was not sending the Host: header then the whole entire internet would fail to work for you. No server would be able to host more than one domain.
-
-
dzm says: Iron 26.0.1450.0 (191758) (a Chrome derivative) on MacOS X 10.8.3 works just fine.
-
-
-
Because I have a few browsers for doing compat testing on my own stuff...
Windows 7 64-bit (fully up to date; dxdiag shows v6.1 build 7601)
Flash Player (fully up to date: v11.6.602.180 NSAPI)* Firefox (v20.0.1): works fine.
* Chrome (v26.0.1410.64m): works fine
* Internet Explorer (v10.0.9200.16540, update v10.0.4): works fine
* Opera (v12.15, build 1748, Win32, Windows 7): works fine
* Safari (v5.1.7[7534.57.2]): doesn't work -- text on player on bottom of screen changes, but no "BUFFERING" nor any audio. No errors on the web console; network tab shows the request to cerebrum as "pending". I grabbed some wireshark captures, but they don't make a lot of sense.
Doing some searching, this came up:
https://github.com/jussi-kalliokoski/html5Preloader.js/issues/8Where they provide a demo case at:
http://labs.avd.io/h5p/And that has the matching work/fail case here (works in Chrome, IE, and FF; fails in Safari... but the demo case fails in Opera, while your code works fine, so maybe not as good a match as I had hoped.
Another link that looks similar:
http://help.videojs.com/discussions/problems/2399-issues-with-chromesafari-pending-requests-loading-mp4sFinally, there are reports that plugins and extension/type maps could cause issues like this:
(I've encountered this myself; on windows, FF will use the OS's extension-to-mime_type map. In my case, whatever unarchiving tool I was using seemed to set ZIP files to map to something odd.)
I did all that testing in the previous 2-3 hours, all coming from the same IP address as this post (68.42.46.144). Maybe your logs will tell you something. :(
-
jwz says:
No idea why Safari on Windows would be the only one failing for you. These are all URLs with the extension ".mp3" and Content-Type audio/mpeg, so that should all be straightforward, too. No Ogg nonsense is even remotely involved.
Seeking, I'm sure, doesn't work for you in Firefox, because they are crazy people who don't believe in MP3, so it has to use Flash for that one instead of HTML5.
-
clicking the "8:40" link for the Fri Apr 19 "Hunky Jesus" results in the 'URL could not be loaded' message for me as well.