I believe the "release note" said something about it being very "drive0 centric" at the moment.

Cheers

I believe the "release note" said something about it being very "drive0 centric" at the moment.



Indeed they did. But I do have to say that using

http://empeg/drive1/fids/101?format

worked just fine for me... ?


Using 156.

Pure luck.

Many of the *1 files use embedded "drive" tags to redirect things.. the Hijack FORMAT feature currently ignores them.

-ml

The easiest way to serve .m3u files (I remember hacking Edna (nice python mp3 server) to do it) is to just serve a "file" with a .m3u extension.. the mime type is audio/mpeg-url and the file syntax is just one URL per line.

Pure luck.




woohoo!

Mamma always said I was the lucky one... Of course, I'm the only one, but that hardly matters....

Need more Coffee...

Sheeshh.. does nobody around here know how to configure a web browser? Or maybe the Windows platform is just lacking good streaming media players?

MSIE allows you to associate files with helper applications, but doesn't let you associate URLs. So it finds a URL that matches some helper application, downloads the file, then points the application to the file. If mp3 streaming was done correctly, it would have been a different protocol tag (shttp?) so you could assign it to a different application to handle. Really, the .m3u file is the best way to handle all browsers as well as adding extra functionality. The click->stream method doesn't let you stream multiple files with one click, so a playlist system is needed anyway..

The problem is that MSIE has no way to assign anything based on mime types at all (correct me if I'm wrong, someone). The only way to assign things to file extensions is to assign them in the basic GUI shell in the same way that makes double-clicking on a file work. It's a real PoS when it comes to this sort of thing.

The problem is that MSIE sucks. It does so many things wrong, that I wonder why I use it.. (Oh yea, the number of things it does right, is more than the other browsers out there).. Argue all you want about how netscape/opera/mozilla translate HTML better/faster/cheaper/whatever, but the UI is the most important thing for a commonly used application.

Yeah, but for this purpose, the UI sucks because it doesn't even exist, nor has it ever existed. It does make most web pages look nice, though. But that probably has to do with the fact that most web designers design primarily for MSIE.

If you want to continue this (I don't), let's take it to Off Topic.

Heh.. I don't.. (Now.. if you could get a URL to enque files/playlists over the web interface... and then a current playlist list.. )

Okay good. Thanks. I've stuck .m3u in the next release (later today), and tried it with MSIE/QuickTime under in my VMware session.. seems to stream..

Maybe I'll tuck in support for .m3u on a leaf-node playlist (not nestable for now, though) before releasing it..

-ml

Cool.. I'm going to throw together a redhat machine and look through the code, if just to figure out how everything fits together.. (And no, I know I can look at the code w/o the machine.. but I would like to be able to compile my own kernels..)

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:

-- mp3: audio/mpeg, audio/mpeg-url

-- wma: audio/???, ???

-- wav: audio/x-wav, ???

Thanks

Thanks Mark, that kinda works. You say it's very drive0-centric but mine won't see anything on drive0, just drive1. Most of my music is on drive0. Oh well I'm sure you'll get it sussed so that it works with both drives pretty quickly. As other people have mentioned it would be nice to have it stream entire playlists too by using m3u files but I know you're working on that. Well done for getting it to this stage so quickly. I know I speak for everyone who uses your Hijack kernel when I say that we really do appreciate your efforts in improving the Empeg experience for us. Thanks

wma is audio/x-ms-wma

Don't know of any additional types for WAV.

>I've stuck .m3u in the next release (later today),
>and tried it with MSIE/QuickTime under in my VMware session
>seems to stream..

Ooops my mistake, I was running v156, and it streams regardless with QuickTime under MSIE -- so it is possible already, but I'll still add the .m3u regardless

That's because quicktime is a plugin, and not a helper application. if you had it associated with winamp, it would download the file first.

here's what I can find:

audio/basic                      au snd          

audio/echospeech                 es

audio/gsm                        gsm gsd

audio/rmf                        rmf

audio/tsplayer                   tsi    

audio/voxware                    vox 

audio/wtx                        wtx

audio/x-aiff                     aif aiff aifc

audio/x-dspeech                  cht dus

audio/x-midi                     mid midi

audio/x-mpeg                     mp2 

audio/x-mpeg                     mp3

audio/x-mpegurl                  m3u

audio/x-ms-wma			 wma

audio/x-pn-realaudio             ram ra rm

audio/x-pn-realaudio-plugin      rpm

audio/x-qt-stream                stream 

audio/x-rmf                      rmf

audio/x-twinvq                   vqf     vql

audio/x-twinvq-plugin            vqe

audio/x-wav                      wav             

audio/x-wtx                      wtx

Edit That was from ImagineX's hosting page.

You know, I was going to point you at IANA, but then noticed that these weren't there. God forbid that Microsoft bother registering MIME types. It's not even like it costs money, AFAICS.

Heh.. so was I, but ran into the same thing..nothing's registered there..

I don't actually know about assigning things based on MIME types, but if you look in the registry under

HKCR\MIME\Database\Content Type

you'll find where MSIE keeps its MIME database.

By "drive0 centric", I mean that it probably won't work reliably if you point it at ANY file not on drive0.. so if your 101 playlist is on drive1, then forget it. This describes your situation exactly.

But you can still point it at any *1 playlist file that happens to be on drive0, and it MIGHT work.

-ml

On mine, it seems to be HKLM\Software\Classes\MIME\Database\Content Type. And it only maps content-types to extensions. Regardless, that's for the entire OS, not just for IE. And regedt32 and regedit are hardly reasonable UIs for, well, anything.

HKCR _is_ HKLM\Software\Classes (possibly merged with HKCU\Software\Classes on W2K/XP).

And IE is an integral part of the entire OS, or did you miss the DoJ's little fracas with MS?

If Mark pulls that off, I'm going to be looking around to buy a rio receiver....

Calvin

Fair enough. Wonder why my search didn't turn it up.

I'd also like to point out that drive1 works for me. drive0 doesn't work at all.

Calvin

thanks I did see that I just wanted to be sure I was even trying the right thing

Dunno. I had a poke around this evening -- there's some CLSID values stored in there, so I thought I'd put together a quick COM DLL and hook it in instead -- to see what kind of things happen when you attempt to download a .mp3 file, but no luck so far.

The other possible avenue is to implement a "pluggable protocol handler", but that looks scary, and is probably overkill.

A .m3u file to enable streaming is simply a list of filenames/URLs.

For example, to get a Receiver server streaming to Winamp, you'd return:

---- cut here ----
http://host:12078/content/12fc0
http://host:12078/content/12fd0
http://host:12078/content/12fe0
---- cut here ----

Winamp would then stream from each of these sources in turn. In this case, each of the contained URLs would have to reference an MP3 stream -- I don't think that Winamp supports nested M3U files.

To simplify things so that they work in most Windows browsers, you need to accept queries of the form:

http://host:port/whatever?parm1=val1&parm2=val2&etc=etc&file=file.m3u

The '...file.m3u' bit works around a problem with some versions of IE (the server doesn't have to do anything except ignore it). You still need to return the "Content-Type: audio/x-mpegurl" header, though.