In reply to:

---

Okay, can anyone there find out and tell me what the Content-Type (mime-type) should be for serving the following audio files/streams from the player

---

If I'm reading into this right, you want to send different headers to get streaming to work for non-mp3 files, maybe in a generated m3u playlist. If you figure that all out, let me know, but I don't know if wma or wav can be nearly as stream friendly as mp3 (or m3u compatible). That's one of the big drawbacks that I was dealing with earlier (though not a big one for me, as all my files are mp3 anyway) when I was trying to enable those file types in my on-the-fly playlists.

As far as getting a good example for m3u, either save a playlist from Winamp or take a look at what I'm doing here when I generate my playlists. It only works with mp3 files though. BTW..my app is based heavily on DisplayServer's funtionality, so this will give you an idea of the look and feel of that.

This one held me up for while.

The "correct" mimetype is actually "audio/x-mpegurl"

-ml

Well, my original point was (I think ) that Netscape has (had?) a simple (if underdocumented) dialog to edit what programs would be used for what downloads depending solely on MIME Content-Type. MSIE has nothing like that. The best you can do is map a C-T to a filename extension and then make that extension's program be something useful under the basic Windows mappings. And I'm not really sure that setting the C-T to extension mapping does anything useful. IE might still base everything solely on extensions, which would mean that if I were sent a file mpegs.txt with the content-type set to audio/x-mpeg-url (or whatever it is), IE might still open it in a text editor instead of sending it to WinAMP. I'm too lazy to test it.

Yeah, agreed that it's a PITA.

In reply to:

---

IE might still base everything solely on extensions, which would mean that if I were sent a file mpegs.txt with the content-type set to audio/x-mpeg-url (or whatever it is), IE might still open it in a text editor instead of sending it to WinAMP. I'm too lazy to test it

---

Nope, it handles file types properly, if a proper header is sent. I send mp3 files and playslists as .php files, and IE handles it just fine.

Any idea what the convoluted process is to associate Content-Types to programs? Surely, regedit could be avoided.

Gosh I think you're probably right...it doesn't have a way to really do that in any kind of simple fashion. Yes, a bit of a PITA. Just uses Windows application associations.

This is now way off topic, but we should be close. Sorry, folks.

The problem is that, on my W2k machine, I don't see any UI dialog that allows me to do anything with MIME Content-Types. Certainly not in the Folder Options->File Types dialog. So what if you had a PHP script that returned an ``application/x-foobar'' C-T? Foobar is not a Microsoft-approved product, so I'd need to add this myself. I can't rely on filename extensions, since I'll be getting what appears to be a .php file. Where do I do it?

Okay, here is what your site is actually sending when it sends an m3u playlist down:

#EXTM3U

#EXTINF:253,Danzig - Dominion

http://mp3.everonn.net/v2/getfile.php?fid=3230&playlist=1

And then the mp3 file is sent (when requested) like this:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

Date: Wed, 30 Jan 2002 23:16:51 GMT

Content-Type: application/octet-stream

X-Powered-By: PHP/4.1.1

Content-Disposition: attachment; filename=Danzig - Dominion

Content-Length: 4049316



............................................

...........................................

(the dots represent the actual mp3 file data)

So, first off.. your app is not using the correct mime type (content-type) for the mp3 data: should be set to audio/mpeg or audio/x-mpeg instead of application/octet-stream.

And the header (the #EXT lines) for the m3u looks rather peculiar.. maybe that's an early form of HTTP/1.0 headers or something.. I'm not familiar with it (but then I'm just learning HTTP on-the-fly here).

Can anyone enlighten me?

thanks

The #EXTM3U stuff is part of the .m3u file. It's actually an ``extended'' .m3u file that contains some metadata about the files it's referencing.

The reason that app/oct works is because the m3u file has already been fed to an mp3 player and it knows what to do with it. It should be corrected, though.

Oh -- and HTTP headers are canonically ended by a blank line.

wfauk: This is now way off topic, but we should be close. Sorry, folks.

Every so often I stumble across a thread here that I wasn't initially interested to read but which I ultimately discover and find very edifying. I can't explain why exactly, but this is one of those threads.

There's OT and then there's OT. this is *good* OT

Thanks for the info. I was wondering whether or not I'd have to fake out the filename extension.

But everything here (except windows media player) seems happy with what I currently have (unreleased), without any strange extensions needing to be faked. And I have no intention of worrying much about WiMP -- MS can fix their own bugs. Actually, WiMP 7.1 is newer than what I have, and perhaps it works too.. maybe I'll try it.

v157 should be out later tonight.

Cheers

Oops.. correction, HERE is what gets returned for the m3u file from your site:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

Date: Wed, 30 Jan 2002 23:38:48 GMT

Content-type: audio/x-mpegurl

X-Powered-By: PHP/4.1.1



#EXTM3U

#EXTINF:246,Fates Warning - Eye To Eye

http://208.139.38.181/v2/getfile.php?fid=960&playlist=1

Can anyone explain to me what the "246" means in this line

#EXTINF:246,Fates Warning - Eye To Eye

??

As far as I can tell, there's some sort of internal association in Windows between the audio/x-mpegurl header type and .m3u extension, as whatever program is set to handle that extension is the program that opens when that header is sent. I don't see a UI anywhere that deals with that, but I just associated .m3u with a different player as a test, and requested a .php file to the browser with the mpegurl header and it opened up in that new program. There's nothing in the PHP script itself that would designate ".m3u", but even when I right click the link to that php script it wants to save it as a .m3u file. It just knows somehow. Color me baffled.

Netscape behaves differently (I just installed Navigator 4.08 to test). It prompts me for the program to open that header type with (as there's no current association), and when I try to save the link (playlist), it wasts to save as .php instead of .m3u. IE seems smarter (but less configurable) and just knows it's a playlist (m3u) from the audio/x-mpegurl header.

In reply to:

---

Can anyone explain to me what the "246" means in this line

---

Song length in seconds.

Never mind.. seems to be the playing time, in seconds, presumable for the next tune in the m3u. Btw.. there's another bug in those PHP scripts, in that they show a playtime of "4:60" for a 240 second long tune.

Cheers

In reply to:

---

your app is not using the correct mime type (content-type) for the mp3 data: should be set to audio/mpeg or audio/x-mpeg instead of application/octet-stream

---

Yep...I did that purposely, because I'm using the same script to offer D/L of mp3 files, and when I sent the correct header for mp3 files it acted differently for people depending on their browser settings. This way, when they select "save mp3" in my app, it forces a Save As dialog box. When the URL is called from a Winamp playlist, however, Winamp just plays it anyway, so I didn't care so much about being "correct".

In reply to:

---

Btw.. there's another bug in those PHP scripts

---

Yeah..never said it was finished or bug free

OK, thanks Mark. I'll have a play with it tomorrow. I'm off to bed now. Goodnight .

> v157 should be out later tonight.

SWEET -- with v158, WinAmp now pops up and starts playing immediately. Wicked.

WTF, I clicked BACK on my browser and v159 is up...


(know I'm not adding anything useful really, just a w00t from someone who's been following this thread closely)

p.s.: Mark (trivia bit here) -- my initials are RTR and I'm in Canada, and RTR.CA was on my list of domains I tried to reserve when the deregulation took effect. Now I know who it went to!

(addendum)

v159 now plays a whole playlist!

Oh goodie! At least some of it actually works!

v160 will be out shortly as well, with a small bugfix for the situation where someone tries to browse to a directory without a trailing slash attached..

v160 also has a new feature, whereby the kernel looks for "/sbin/hijack" as a replacement for "/sbin/init" on booting..

-ml

Ha! We got rtr.ca a year before the deregulation. Gotta love short domain names, eh!

-ml

Oh yeah, does Winamp also now display the titles of the tracks correctly?

v158's /proc/empeg_kernel writing from FTP is broken. I got an assload of

Flash driver: mem allocation error

end_request: I/O error, dev 3c:08 (flash), sector 982

with the sector number steadily increasing (982 was the last). Didn't upgrade the kernel.

BTW, shouldn't this thread be in Programming now?

(sorry if I drag this off further, but I've got nobody nearby who'll appreciate how cool this is)

Right now, as I type, I've got my empeg playing normally with empegVNC serving the display to my PC, while WinAmp streams a different playlist entirely off the empeg (thanks to HiJack v159), while I FTP off several hundred megabytes of work data (again thanks to HiJack) to the same PC.

No gaps or skips in the audio. The vis on empegVNC is dropping no more frames than normal and the display on the empeg itself is not losing frames as far as I can see. I can't give you a throughput measure on the FTP since the files are too small and my FTP client doesn't show overall bandwidth.

COOL This thing SO has overhead to spare.

FYI, here are some vital stats on the player right now (its been doing this for 10 minutes now)

MK2a: 29G, +35C/+95F
Playlist:0000, Fid:
Cac:480-510s, Buf: 81, Fre:80-120s
LoadAvg: 2.10, 1.71, 0.89

K, my fiancee just dropped by, showed her what the empeg was doing, she said cool, but I don't think she appreciates it fully. She just said 'Linux...?' knowingly.

Weeeee! (thats glee, btw)

Oh yeah, does Winamp also now display the titles of the tracks correctly?

It displays them fine, until you try to play the file, then it tries to load them from the mp3 and finds no tags, so it just displays the filename.

ok my fids 101 is on drive0 now
I am trying http://192.168.0.5/drive0/fids/101?format with no success.

anyone know what I am doing wrong

Thanks

> Oh yeah, does Winamp also now display the titles of the
> tracks correctly?

With v159, I am only seeing the FID. (glee undiminished.)

new format, changed a version or two ago, should be..

http://192.168.0.5/drive0/fids/101?.html