I have read the FAQ and didn't find the answer i was looking for .So my ? is, can i use player on home PC and hear sound without using the RCA outputs.Will the computer just pull the file(song) thru USB and play it on Winamp thru the computer speakers?My apologizes if this was already discussed but i didn't find the info. Thanks Mike.

No you can't, though I wish you could.. I only have one RCA->phono cable.. My Nomad Jukebox can, so it's not impossible.. Just need someone to add that feature to (J)emplode or some other application. The alternative, is to port shoutcast/icecast to the empeg..

You can use Display Server to play over ethernet. You can also install Hijack and point Winamp to the player's IP address (also ethernet) to browse its contents. Unfortunately you'll only be selecting by FID# and won't know what you're playing until you hear it.

Bruno

You can't just take the front outputs and use an adapter to plug it into a soundcard? You may want to watch keeping the volume down of course. My soundcard has a "line input" that I've plugged my home receiver into, I can't see the Empeg being much different. Be careful of course, if it's spitting out too high a voltage I guess you could hurt something.

The adapter is easily found at an electronics store. It's designed to connect a portable CD player to a stereo, but works in reverse.

just install display server it works great

here is the faq instructions Link

here is franks website Link

get version 1.1

So my ? is, can i use player on home PC and hear sound without using the RCA outputs.

You can (using Displayserver or Hijack), but why would you want to? It's much easier and better if you simply connect the car player into the PC sound card's LINE INPUT jack. How to do this, and the advantages of doing it this way, are described in this FAQ entry.

I use mine that way because I have usb speakers

I use mine that way because I have usb speakers

Ah, yes, those wonderful useless pieces of stillborn technology.

I don't miss my hissing sound card

Which version of the player software are you using? I've found DisplayServer to be broken when running the 2.0 betas. Other guys on the network get a connection but it's very flaky. They get lots of timeouts now. I have mentioned this on the BBS before but no-one's really given me any indication whether they also have this problem or not. I'd really like them to be able to listen to my music collection again.

So what does displayserver do for tunes.. does it present a playlist menu or something, and then just allow you to click and stream over http (ala Hijack, without the playlist menu)??

Thanks

does it present a playlist menu or something, and then just allow you to click and stream over http (ala Hijack, without the playlist menu)??

Correct.

I think it would be cool if Hijack could have a symbolic link to some code that on-the-fly generated a playlist menu like Displayserver.

As I understand it, it actually generates an .m3u file that it sends to the client, right?

I am using the player 2.07 developer version and the displayserver version 1.1. I have gotten a couple of timeouts I am just using it on my little home network

Anyone remember this program?

Only problem is it's not on-the-fly.

Tom

I think it would be cool, too. I might just have a look at it..

-ml

That's about it yes. DS1 & 2 differ in the way they display the information but functionally they're very similar. You get your playlists layed out in a table which you can click to see the contents of (be this further playlists or tracks, or both). You also have the option of just streaming individual tracks or whole playlists. It doesn't seem to handle the playing of nested playlists though. It would be nice to get it working properly or add to your HTTP server to get it to serve up some nice output like DS.

Any chance of getting this into Hijack?

edit: you just beat me to it. Yes it would be really cool if you could get it in there .

Just re-read the question, now realizing that the question was how NOT to use the RCA's... sorry about that.

Mmm.. Okay, I have the basic skeleton functionality in Hijack now.

It added about 1KB or so to do, and is extremely plain brown wrapper at present. I'll upload it shortly (v155).

If anyone wants to experiment with it, just point your browser at your empeg like this:

http://my.empeg.whereever/drive0/fids/101?format

Note that it is very "drive0 centric" at the moment, and not fancy in the slightest. But it does work.

-ml

/me scrambles for his player and version 155....

Yup, that works. Just like displayserver. Except when you actually drill down to an individual song, it doesn't start streaming when I click on the song link (assuming you'll work on that?).

Too cool.

Mmm.. when I click on songs, they stream for me..

I wonder what your browser is expecting different?

Cheers

-ml

I've tested on IE 5.5 and 6, and Netscape 4.08. In all cases, the songs don't stream..they download to a temp directory and after the whole file is copied it begins to play.

Seems the difference is DS generated and sent .m3u files on the fly (audio/x-mpegurl), and Hijack sends just sends the mp3 file. I guess.

In reply to:

---

You can (using Displayserver or Hijack), but why would you want to?

---

Improved sound quality for those of us with digital connections to our recievers from our soundcards.

OMFG this is good. And so easy!

I've tested on IE 5.5 and 6, and Netscape 4.08. In all cases, the songs don't stream..they download to a temp directory and after the whole file is copied it begins to play.

Seems the difference is DS generated and sent .m3u files on the fly (audio/x-mpegurl), and Hijack sends just sends the mp3 file. I guess.

I agree. I have quicktime as my default player and I can see the file downloading. It can be played at any time once the QT player comes up.
Using opera 6 it downloads the file and uses the default media player.

No streaming at this point.

ok here's a dumb question what directory do I go to, to see the playlists ?

I have version 156 Mark was too fast for me

If you've used Hijack before to browse you player than this should be pretty straightforward. You would be in your FIDS directory, and looking at the 101 FID, but passing it the format parameter, like:
http://whereveryourempegis/drive0/fids/101?format

http://my.empeg.whereever/drive0/fids/101?format

Very cool! Now serve them to Rio Receivers and we can all go home

Peter

my 101 is on drive1 it doesn't appear to work from drive1
unless I am still doing something wrong

http://xxx.xxx.xxx.xxx/drive1/fids/101?format

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

It streams, and plays, "out of the box" for me using Netscape with plugger. The mime-type is (correctly) "audio/mpeg", and plugger just streams it into mpg123 in the background.

But of course this ties up a connection for the duration, and Hijack only allows four connections max by default, so better might be to download it and then play it. With this mode, it is extremely simple to edit the "helper applications" settings and add the audio/mpeg mime-type, pointing it at a suitable mp3 player (are there any on Windows?).

But if you'd rather have ".m3u" output, then somebody please post an example (complete, please) of webserver output for a ".m3u". Thanks.

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.

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

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

What are you doing on 159??? 160 is out!

thanks I didn't look at the notes for 157 since I went to look for a newer version and 160 was there already

> What are you doing on 159??? 160 is out!

OMG I am like so ten-minutes ago.

One more thing.. Do you have resuming downloads on your list of things to add? Without it, it's impossible to scan forward into a track..

For some unknown reason, W2k's FTP mkdir command executes ``XMKD'' on the FTP control connection. Any way you can add this command? I can work around it, but it's a minor PITA. Would add to client agnosticism (I guess)...

This is great.

I can now queue an album, or at least a playlist within which there are actual tracks.

Still can't queue a playlist if there are no tracks at the next level down, that is, there are only further playlists. Example:

<top>/Artist/TOOL/Lateralus/Schism

I can only queue the playlist starting at 'Lateralus' or cue 'Schism' individually, but no higher. Clicking 'TOOL' or 'Artist' just drills down to the next level.

Clicking 'Play' on a track pops up WinAmp directly, although no ID3 info is available. If I click the track title, I am prompted to download (which I assume is intentional.)

That's not hijack, that's the flash-empeg.c driver.
Just try it again; if it still fails, you may need to "reserve" some memory in config.ini to make it more reliable.

Cheers

Could you please send me an EXACT copy of the "XMKD" command from your client? Thanks.

Never mind. I found the command (and some other..) in a REALLY ancient RFC-775 that predates the "modern" RFC-959 for FTP. I've added XMKD and XRMD for v161 (later tonight).

-ml

Sorry. Just never saw it before in many uses of the feature, and that was my first try under v158.

>I can now queue an album, or at least a playlist
>within which there are actual tracks.
>Still can't queue a playlist if there are no tracks at the
>next level down, that is, there are only further playlists.

Yes, that behaviour is intentional.. I added code to do exactly that, to avoid having recursion inside the kernel.. (generally a Bad Thing(tm), especially in kernels). So for now, I think it will stay that way.

Cheers

Yeah. Apparently, Microsoft thinks that their users have more need to FTP to a 1980-vintage Tops-20 machine than, well, anything updated in the last 15 years.

>This thing SO has overhead to spare.

Well, it has a little bit to spare, but you will notice that if you "pause" the mp3 player on the unit, your FTP speed probably doubles..

Cheers

>Do you have resuming downloads on your list of things to add?
>Without it, it's impossible to scan forward into a track..

Sounds like an application bug..

But I'll add RESTART to the features hotlist, for both FTP and HTTP.

Great work Mark. This thing's progressing nicely. Mine will still only see the tracks on drive1 though. Is this a known problem or have I missed something somewhere? Sorry if I'm being a jerk.

The release notes said something about "two drive systems will still have troubles".

To help fix this, could you please grab ALL of your /drive0/fids/*1 files and tar them up and send me the .tar file for them, and then do it again (separately) for /drive1/fids/*1

That way, I'll have enough data to reverse-engineer how things work, so I can add two-drive support for the playlist browser.

Cheers

Well, scanning using HTTP uses the RESTART field. What happens, is that the server ignores it and starts from the beginning..

I just noticed that pressing the knob button once does nothing while there are no menus up. Works normally for the Hijack long press and, to my testing, when any menus are up. I have not modified config.ini in any way from the stock install. Is this a feature that I missed somewhere? If so, nice job! If it's a bug, move it to the features list.

Naw.. you probably just don't have a PopUp0 defined in config.ini, and your "Knob Press Redefinition" in the Hijack menu is set to "PopUp0". That will surely disable short knob presses..

If not that, then I dunno what you mean

You're right. Seems to me that it should probably default to [default], given that I haven't set anything up at all. Not that I'm really complaining, since I hate accidentally pulling up the sound controls.

I'm adding "restart" / "resume" / whateveryacallit support to Hijack v161. The FTP side appears to be working well, but I'm not likely to test the HTTP side as much before release.

So give it a whirl (after v161 comes out) and let me know if it works for you.

-ml

Let's move this discussion over to the v161 topic under "Programming", folks.. otherwise I'm likely to miss out on future postings here..

To help fix this, could you please grab ALL of your /drive0/fids/*1 files and tar them up and send me the .tar file for them, and then do it again (separately) for /drive1/fids/*1

That way, I'll have enough data to reverse-engineer how things work, so I can add two-drive support for the playlist browser.

Reverse-engineer what, exactly? When looking for any given fid (whether a *0 or a *1) the player will try /drive0/fids first, and, if it's not there, /drive1/fids second. There's absolutely nothing clever about it, and absolutely nothing anywhere else that tells the player which drive a given fid is on.

A smart move would be for Hijack to do the same, and just present a fids namespace which is the union of /drive0/fids and /drive1/fids.

Peter

Ahh. okay, that's simpler than I was expecting.

Perhaps I misled myself, because I noticed some "drive=0" tags in some of my /drive?/fids/*1 tag files.. any idea what those are for??

Perhaps I misled myself, because I noticed some "drive=0" tags in some of my /drive?/fids/*1 tag files.. any idea what those are for?

Um, my guess is that they're vestiges of a half-implemented feature, abandoned when we realised that nobody really needs to know which drive a fid is on. Sorry. ISTR there's even a drive column somewhere in Emplode, full of zeroes.

Peter

abandoned when we realised that nobody really needs to know which drive a fid is on.

Argh, no, don't abandon that! We need to know the drive of a FID!!! We really do!

PLEASE don't abandon that feature, please please please!

Argh, no, don't abandon that! We need to know the drive of a FID!!! We really do!

PLEASE don't abandon that feature, please please please!

Why do you need to know? I'm puzzled, as that feature has never, ever worked and no one has ever complained (much). (Roger, don't post saying you fixed it, because sometimes the *1 file is on the other drive than the *0 file and emplode can't possibly know.)

Peter

What I would like is for Emplode to tell me where the given *1 and *0 files reside so that if I ever need to directly go to the file and perform surgery or extraction on it, I can.

Emplode neither knows nor cares which drive the files are on.

What I would like is for Emplode to tell me where the given *1 and *0 files reside so that if I ever need to directly go to the file and perform surgery or extraction on it, I can.

If you're going to perform surgery or extraction, you must have access to the player's filesystem. And if you have access to the player's filesystem, you can find out for yourself which drive a file is on. (The price of at most one failed stat is negligible compared to any surgery or extraction costs.)

I still think that nobody ever needs to know which drive a file is on, except in circumstances when you can easily find out for yourself.

Peter

And, having talked to Peter, I agree with him, I've removed the parts of emplode that dealt with the drive field.

RITNR.

>What I would like is for Emplode to tell me where the given *1
>and *0 files reside so that if I ever need to directly go to
>the file and perform surgery or extraction on it, I can.

The Hijack HTTP server can be used to access the raw files without much trouble, even without knowing which drive they're on (it will search both drives).

Cheers