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