The "memory detection" logic used in v2.01 and v3a8 could be improved.

It currently does stat("/proc/kcore") and takes the returned st_size value as the basis for memory size, which is good. But the way it uses that value is not always the best.

It appears to first determine the type of unit (Mk1, Mk2, Mk2a) it is running on, and then assumes a certain base memory size based on that. It then subracts this base amount from that reported by stat("/proc/kcore"), and calculates cache size based on the difference.

But it does NOT check for a negative number here, which means that if the kernel under-reports the size, the player will try to allocate HUMONGOUS amounts of cache (gigabytes), and die a horrible death.

It would be better if, for Mk2/Mk2a, the player software could simply accept the value from stat("/proc/kcore") and subtract it's fixed overhead (and ReserveCache setting) from it, and calculate cache size based on this result.

Background: Hijack would like to obsolete the need to twiddle with ReserveCache settings, by providing a menu function for this instead, which simply tweaks the reported memory size returned from stat("/proc/kcore"). This would allow Hijack to account for its own overhead automatically, hopefully reducing the incidence of mysterious player crashes.

Cheers

Another one - don't know whether it's in earlier alphas (anyone with v3a7 care to test??).

When 'repeating all' of a shuffled playlist, at the end of the running order, the 'next' track appears to be selected before the running order is reshuffled and de-dup'ed. This means that you are never at 1/XX in the playlist, but at some random position (eg 56/XX) based upon where the new track ended up in the shuffle.

I guess that for a purely random shuffle this shouldn't be too much of an issue. But for weighted shuffles (eg 'newest first', or emphatic's 'favorites') it is a problem.

Why is the order reshuffled when repeating anyway?

One more (at least I haven't noticed anyone mention it)...

The volume Auto Gain seems to be significantly more aggressive in b8 than b7. It ramps the audio drastically at the beginning of a song so it starts really loud and then backs off over the course of the next couple seconds. Even happens with gain control on low. Its annoying enough that I've gone back to using hijack's voladj for now.

-Mike

I know a9 didn't work for many people, but I’ve been using it for quite some time now. I'm about to go back to a8. But I figured I’d post this first.

In the car, my player always seems to lockup after a playlist ends. The UI will still function, well mostly. The track title usually always is locked on the last track in the playlist, but the play/pause icon toggles on top button press. The TrackNumber area does update on left/right presses, but the Title remains frozen with no audio output.
I'll hold the top button down to get into standby, then remove and insert back into the cage.

Another thing is it seems, in the car, the drives are always spun up, even with the latest HiJack. The Disk Icon is the gray background one with 3 dots on the right of it.

I also didn't loose a single playlist on upgrade from 2.0 -> a9

I also haven't been using the player at all on AC recently so I’m not sure if these bugs are present on AC.

Ok, I know I still shouldn't be running alpha 9, but i just haven't had any time to downgrade my empeg lately.

Anyways, Last night I was adding a new album onto my empeg. This time i used jEmplode for the first time to modify my database. It uploaded the album, but the playlist wasn't where I put it, nor was it any visible place on the empeg. Trying to load it with the set PIN number caused the player UI to crash (sitting at the hourglass). However hijack was still working for a long knob press.

After about 4 attempted syncs with jEmplode, each time I did something it would screw up my playlists even more. At one point last night all my "G" albums disappeared. Finally I installed the USB driver (I was using ethernet), and loaded up emplode, and it decided to do a disk check.

So that was at about 4am, I left the empeg syncing and went to bed. When I woke up, the error that it lost the connection during the reboot, so I unplugged the power to see if it at least built the database and it didn't (had to wait around for 5+ minutes for the manual empeg db rebuild)

After a few more sync's I had all my G items back, minus the album i was trying to add. Emplode saw it, but the empeg would never display that playlist under g, or anyplace else. So I deleted that album, and added it again with Emplode. Worked perfectly, well almost, still the same connection timeout message after the reboot, but at least the new album in on my a9 player.

So, now I’m at work... had to bring my cables with me today so I could have music on the way home. So I figured I’d use the http web server to steam some tracks. This is where I’m a bit scared.
HiJack doesn't see/display my actual playlist structure. Which is at the root level "!", "#", "A-E", "F-J", "K-O", "P-T", "U-Z", what it does display is each letter of the alphabet, and a "VA" item which I’m guessing is for Various Artists. The only catch is i don't have that structure at all.
I'm also sure that fidsift'ing my fids probably wasn't the best idea while running alpha software, but either way, my fids are sifted, with noticeable speed improvements for browsing playlists, and DB rebuilds.

Whoaaa!

1 minute 25 seconds is now 18 seconds!

But something else is wrong; the player is forgetting some of its
settings, like info mode and current playlist. Maybe more, I'd need
to check.

Pim

Hmm, very strange.

I was running v412 before trying the test image. Then went to plain v417
and then back to v412. The playlist amnesia seems persistent now.

All the time I was using a playlist with some 5500 entries. This has
always fit, unlike the root playlist with 20063 entries.

Pim

Yeah, I think something's wrong there.

I'm actually on the road here this week, and so testing stuff is difficult for me.

But I'll take a close look and see what turns up, and try another test kernel in a day or so perhaps.

Cheers

Okay, found the bug, fixed it.

http://rtr.ca/v3a8-hijack-zImage

Cheers

"Elk nadeel heb z'n voordeel"

This is a famous saying by Johan Cruijff (Holland's best ex-soccer player ever)
which is bad Dutch for "every disadvantage has its advantage".

Now that my player forgets the current playlist no matter what kernel
I use, I might as well use the one that starts up fast ...

There's no need to hurry, I'm at home with a flu anyway.

Thanks,
Pim

Oops, hadn't seen your fix when I posted my previous message.

Are you sure you made the right image available?
Startup time is back to 1:15 and playlist amnesia is still there.
Here's the md5sum:
768c8282d1c15b879bc260f92d97bc8a v3a8-hijack-zImage

Pim

Yeah, the right one is there, and yes, it still has amnesia..

Does it (latest) also improve your startup time? If so, I'll fix the amnesia and then do a proper release of it.

Thanks!

Like I said, the startup time is now 1:15, so only slightly faster.
BTW, all startup times mentioned are from power on.

Pim

Ah, well nevermind it then. The first (faster) version was faster because it was buggy.. didn't actually work correctly.

For the amnesia, my player went back to normal when I reloaded stock Hijack onto it, and then selected a small playlist from the menu, put player into standby, powered off a few seconds later, and rebooted.

If yours persists in forgetting about it's playlist, then I'd suggest a wipe of the dynamic data partition should cure it; somewhat extreme, I know, but if it persists..

Cheers

If it's a #define in the player, then it would be very difficult to patch.. they probably use the #define to statically declare a buffer of appropriate size.

Cheers

Yes, that's what I was afraid of.
Let's hope this gets fixed in july ...

Pim