Hijack v396: fixes for v3alpha8 (non RE version)

Hijack v398 is now available.

This version includes a fix for the unresponsive behaviour of the player software (all versions) when the player is buffering track data for later playback. This fix is particularly noticeable on players with expanded memory, as well as those running v3alpha8, but should be helpful in other situations as well.

Recommended for all.

Cheers

I'm glad the freeze on buffering problem is something that is fixable from hijack. It's milding annoying with 32MB but I'd imagine its a right royal pain in the arse for 64MB and up! I assumed it was some thread priority thing within the player. Once you've sorted it, would you mind telling me what you did?

I just hacked the read() syscall to recognize when the player is reading music files, and have it break the 64KB reads into smaller chunks, with a short scheduler delay() call between chunks. Changing the thread priority would be another approach, but the 64KB chunk size is still too large for that approach to work as well as how it's now done.

Cheers

I really must be getting to grips with linux now because almost all of that made sense.

Hey, that sounds great! Sometimes I get a volume "jump" because it's buffering while I'm turning the volume knob (on 2.0 even). Think this'll help prevent that problem?

Yup, should fix it.

But hang on a sec.. v399 coming out shortly..

Hijack v399 is now available.

The only change is a one-liner to prevent crash loops with the visual immediately preceeding the (already fixed) Lavoratory Floor visual -- fix needed for v3alpha8 only.

Cheers

Is it just me or have other the same behaviour. Even with the latest Hijack kernel (413 at the moment) my player suffering from the following problems:
- lavatory Floor visual crashes player
- unresponsive player during readahead

According to the hijack history this problem should be solved?!? Seems the fix does not work for me.

Another strange thing: Whenever I try to reboot the player through the hijack menu entry I get the following core dump:

empeg-ca((d((((da(((d(d(((((d(((((d((((d(d(((d((((da(((((d(d(((d((((((d(((d((((d
(d((((d(d((((((((d(d(((d(d((da(((((((((((dat(((dat((((((((da(((dat((((da(((da(((
(((((da((((((da(((d((((((((((data(d(d(((data((((d(((((((d((((((((d((((((((d(d(((
d((((((((d(da((((((da((((((((((da(d((dat((((d((((d(((((d((d(((((d(((((((((((((da
((d(d(dat(((d(dat((((da(((da((((d(((((d(((da(((d((((((d(((d((((d((((((((dat(((((
(((((da(((((((((((((((((data a((((((((((((((((((((((d((((d((((((d(((((((((((((((
(((((((d((d((((d(((d(d((((((((d((((d(d(((da((((((((data((((d(((d(d(((((da((((da(
(((d(((data(((d(((d(da(d((((((((d(((((d((data abort vector)

Running v3alpha8 / 32MB RAM

I have never figured out why some Hijack versions "reboot" okay when others do not. And sometimes it varies from player to player even when running identical versions. I think it has to do with the flash bootloader "assuming" something about initial memory contents..

The other issues.. well, most of the time the lavatory floor crashes seem to automatically resolve themselves with recent Hijacks -- before Hijack "fixed" it, this was a non-recoverable crash loop, requiring intervention over the serial port to restart the player manually with "player -i" which also wipes away tons of nice settings.

Cheers

I just now checked out the lavatory floor and responsiveness issues on my 32MB v3alpha8 player with Hijack vlatest, and no such problem.

Sure, the lavatory floor still crashes the player (nothing I can do about that), but it restarts and carries on by itself (courtesy of Hijack).

And during disk-read-ahead, responsiveness is only 70-85% of normal, but that beats the 0% that it gives without Hijack.

Cheers

You're absolutly right. Didn't know much about the alpha8 behaviour without hijack.
Sorry for any confusion.