Hijack v268 is now out.

The only change is a one-liner to the EMPEG_HIJACK_WAITMENU ioctl() call, which should now cause it to remove the userland menu items between calls.

So, if an app.. say.. a menu multiplexor.. binds several menu entries at once and waits for one to be selected (that's what EMPEG_HIJACK_WAITMENU is for), then on exit from the ioctl(), the menu entries will have disappeared again.

Or at least in theory. I have never used userland menu entries, so this one-liner is completely untested. And it includes one certain bug that will crash Hijack... a free trophy (of sorts) to the first person to find the bug!

Cheers!

Mark

I've now put out Hijack v269, with a few minor changes:

-- The delay at startup has been cut back to 0.5sec (instead of 1.0sec) -- tfabris will have to let us know if this still keeps his animation daemons at bay.

-- the default animation has reverted back to an older one that I really like better than tux-shorts.

-- a couple of extra lines of code in the ext2 filesystem name matcher may speed up database builds/etc. a little.

Cheers

Mark

Mark, do you provide diffs between Hijack versions? I couldn't find them on the Hijack web page (slap me with a fish if I've missed an obvious link). It's often instructive to see what you've done, and it's getting more and more difficult to find changes as the Hijack diff grows...

If you have a v268-v269 diff, I'd like to see it.

Ehh, I think what you are looking for is at the HiJack homepage (At the bottom of the page) linked from the top of the BBS page.

Unless you mean something else by diff. than difference

TommyE

In unix you can produce patches to source code with a utility called "diff" so that only the changes to the source have to be downloaded. These patch files can also be called diff files.

John

OK, so thats what diffs are.

TommyE

I'll be out of town starting in a few minutes until tuesday, so this doesn't really matter, but thought I'd let you know what was going on with the latest hijack version, even though I might not be able to give you enough information to fix it until tuesday. First of all, in most cases, unbinding a program from the list works fine. For example, if I run a program that binds itself to the menu, then send it a SIGINT, it will close itself and be removed from the menu. Thanks a lot for implementing this for me! I am, however, still having two other problems.

The first is that I'd hoped that there'd be a way to change the menus during the runtime of a program, but its not working for me. This would work something like: make a WAIT_MENU ioctl call with a given array of strings (menu), get the menu index, process it, make a new ioctl call with an updated array and have a new menu. Unfortunantly, right now it seems to leave old items from the first call there the second time. On tuesday, I can send you a short bit of source code that shows this, I think.

I only think I can, because I've been getting crazy other weirdness recently as well. I think it might be the bug you mentioned, but it could be an altogether new one. I don't know what I've changed to cause this, but now when I call the hijack WAIT_MENU ioctl (I've isolated it down to that line of code) the screen goes black and the player exits. (I can still 'q' from the serial port and drop to shell) And my program is still running after i get back into shell. Go figure. Maybe I've somehow corrupted the array of strings, I don't know. I really haven't had time to check it out. But I'll get back with more info in a few days, just wanted to lets you know some issues that were going on.

Thanks again for your help.

John

No, I don't.

In reply to:

---

a couple of extra lines of code in the ext2 filesystem name matcher may speed up database builds/etc. a little.

---

I found this, and don't see how that helps - in the music directories, the last character will terminate the match about 50% of the time (as half the files end in 0 and half in 1], whereas the first character will terminate the match between 70% (if I have files up to, say, 1FF) and 93% (if I have up to, say, FFF). So how does this change improve the speed? I'm sure I've missed something that should be obvious - but what?

If the cost of calling memcmp is really so great, wouldn't it be better to inline it completely?

On my 60GB unit, nearly all of the files in each of the two FIDs directories are named beginning with a '1'. So a fast check of the first character would not buy much. But since a quick look at the final character can eliminate 50% in one fell swoop, on anybody's unit, it is probabably (not quantified yet) a win any place that it matters much.

On most Linux platforms, memcmp is inlined, but not on the empeg. Dunno if it is better this way or not, since plain dumb inlining is not always a good idea -- depends on the architecture and how it handles caching/lookahead.

My 60GB unit feels faster now. Purely subjective, no doubt.

-ml

v2.0-beta13 will support a partitioned FID directory. It doesn't create one (the CVS trunk build does, which is why I had to back-port it into the car_v2 branch). I've not tested it for rebuild speed improvements.

That sounds cool. What is the basis for partitioning? First two characters? Final two characters?

Just the first character by itself probably is a loss, or would be on my player, as it is almost always a '1'.

Cheers

On my system, fewer than 1/4 of the files in /drive0/fids/ begin with '1', but most of the files in /drive1/fids/ do (drive1 was added quite recently, so it's not huge).

I'm still confused by the mathematics of this.

Suppose the fids directory contains all FIDs up to n digits, and all the (n+1) digit FIDs that begin with 1. Then we have 16^n that begin with 1, and 16^n others, of which 1/15 begin with 1. So 17/30 begin with 1 - only just more than half. If we now increase the number of FIDs, the new ones all begin with 2, so the proportion that begin with 1 decreases, until we fully populate all the (n+1) digit FIDs, at which point all initial numbers are equally distributed 1/15 each.

Perhaps you have lots of 1* FIDs as a result of deleting old (short FID) stuff?

In case it's not clear, I'm not accusing you of being wrong to add this code; I just want to understand the logic of it a bit better. Maybe we could do even better by comparing the last-but-one character (which is most likely to be uniformly distributed 16 ways)? After first checking length>1, of course... Hmm perhaps re-implement a variant memcmp that starts at the end, inside ext2_match()?

Assuming the FID was 0xAAAAABBB (including leading zeros), it'll get put in /driveN/fids/_AAAAA/BBB, where N is worked out by the normal method (drive with more space on it).

The player looks in the new location first, and if it can't find a file in there, it'll look in the old location.

Hi.

Assuming the FID was 0xAAAAABBB (including leading zeros), it'll get put in /driveN/fids/_AAAAA/BBB, where N is worked out by the normal method (drive with more space on it).

This seems to be a pretty bad logic, at least if your intention is to evenly distrubute the files across a number of directories.
I will assume a single drive empeg for the following explanation, but this shouldn't actually change the math.
Assume we start with an empty empeg. If we put 16^7 files on it, thus filling your above template to the max, the will be equally distributed across all directories. BUT if we only but 16^2 files on it, only directory /drive0/fids/_00000/ will be created and filled (with 512 files). This would mean that only directories _00000 to _000FF will probably ever be used (65536 tunes/playlists plus corresponding meta files). Is this your intention? Or are you more interested in building an evenly distributed tree? If that was the case, I would probably use either a hash function or turn FID 0xAABBCCDy (with y=0 or y=1) into /driveN/fids/D/CC/AABBCCDy (allowing, but not requiring leading zeroes). This creates a directoy with 16 entries (which are likely to be evenly used): 16 subdirectories with 256 entries each, less likely to be evenly distributed, but this is probably acceptable. Each of those contains about 1/4096 of all files once filled, but never more than 1/16 of all files. Moreover, this structure is pretty easy to populate from the existing flat directory by the following shell script(bash):

for d in 0 1; do

   for i in 0 1 2 3 4 5 6 7 8 9 0 A B C D E F; do

      cd /drive$d

      mkdir $i;

      for j in 0 1 2 3 4 5 6 7 8 9 0 A B C D E F; do

         for k in 0 1 2 3 4 5 6 7 8 9 0 A B C D E F; do

            mkdir $i/$j$k

            mv *$j$k$i[01] $i/$j$k/

         done

      done

   done

done

This obviously will only move files with 4 characters or more as a filename, but this is acceptable in my opinion. Besides that, this approach is simple and effective, I would say. If your goal is to create as few directories as possible, all of which are guaranteed not to have more than 512 (or, if
there will ever be fids with [2-9A-F] as last characters: no more than 4096) files in them, obviously your method looks better. I would still keep the full filename though, because it allows the user to move his existing files over to the new location. Well, actually, the above move command could be modified to also rename the file (using some sed, awk and/or perl magic), but why should one make it more complicated than needed?

cu,
sven

We're not trying to evenly distribute the files -- that'd probably be bad for directory entry caching. We'd prefer that files near each other in FID order end up near each other in the directories. We _are_ trying to make the root fids directory smaller, so that it's more likely to fit in cache, and speed up the accesses.