Greetings!

I seem to be having a problem with hijack (running 175 at the moment). Today was my first time uploading a quantity of music since the disk upgrades I did. I am having a sync failure as it tries to remount the hard drives rw.

Just as a historical note, I DID test syncs after the drive upgrades with an older hijack. No problems.

I have two different, identically configured units, both with the same results.

After manually fscking both machines, I unloaded hijack from one of them, turned on emplode logging and ran a test. The one running the empeg kernel synced without problem. The one running hijack hung on trying to remount the disks read write, just after the disk check.

This appears to be a new error, because I had performed syncs and configuration in the past. When I tested after the drive upgrade, it was with 151. Right now I am testing with 175. I suspect an error occurred between those revisions.

I have the sync logs, if they would be of benefit...

Paul G.

Sounds to me like Emplode probably just didn't wait for the fsck to finish, since it can take upwards of half an hour on a large drive.

I just tried tune uploads, playlist changes, etc.. with Hijack v178, and no problems whatsoever.

The fact that your system even did a fsck is indicative of some other problem.

Cheers

-ml

Greetings!

The fact that your system even did a fsck is indicative of some other problem.

Actually, this is not the case. The only reason I did the fsck as a starting point was because of the locks on previous sync attempts. The player was hung, and I had to hard boot it. Given that it was midsync, I wanted to start from a known good point. I had the file systems completely clean before the last set of tests.

Emplode probably just didn't wait for the fsck to finish

During the last set of tests, there was no fsck run. (Trust me, my fscks are VERY noticable...) It just stepped through / over that step, into the "deleting old databases" step. At that point, it appeared to try and remount as read / write, and then hung.

For my current upload set, I have uninstalled hijack from both units (running vanilla 2.0b7), and they are working fine. I will reload hijack after the sync. Would the emplode logs be of any use?

I just tried tune uploads, playlist changes, etc.. with Hijack v178, and no problems whatsoever

Keep in mind, my players are kind of the extreme case in terms of disk capacity. I tend to find disk and player timeouts where no one else has problems. Ah, the price that we all must pay for additional space! I will try 178. Perhaps that was my issue.

Thanks!

Have you added these lines to your config.ini yet?

   [Startup]

   ReserveCache=12

Most sync/Emplode failures are due to things not behaving gracefully under low memory conditions, and with the Hijack kernel installed, the amount of memory available is lessened slightly.

Newer betas will have something like this built-in.

-ml

Greetings!

I have ReserveCache=32, if I remember correctly. I am mid-sync, so I cannot test at the moment. I had it high because I previously used Displayserver for my work juke box, and I needed the memory to generate the playlists.

I've noticed on my 60GB RioCar [Mk2A] that a 'rwm' from the bash prompt takes AGES to complete, compared with a rwm on the 12 or 10GB unit.

I wonder if this is due to some kind of buffering being done by the kernel - it rattles away at the disk, but not like a fsck does, more like a scan through the inode table or something.

Interestingly all my units have lateish Hijack kernels installed (i.e. V157 at last count).

And in all cases I'd stopped theplayer to get the bash prompt on serial, so if it was a low memory issue then presumably the player not running would fix that (unless the memory freed wasn't enough).

I wonder if your symptoms are related to this. If so, the try repeating a simple 'rw' and/or 'rwm' from the bash prompt and see if this take ages - this would definately make Emplode timeout I think if it happened to occur.

rwm is SLOW because it doesn't have "nocheck" on the parameter list. As a result, the kernel does a self-admittedly useless partial fsck everytime you do rwm. I think this bogus check got removed from newer kernels, but the 2.2.xx stream still has it.

To speed up your rwm, change the mount options from "remount,rw" to "remount,rw,nocheck". That's what Emplode does, and that's what Hijack does. The rwm script is the only one that does NOT do it by default.

-ml

Makes sense now - I sort of wondered if that's what it was doing, but as I don't intend to do much rwm'ing on my 60GB via bash its no problemo to do it manually whenever I need to do a rwm without the long pause.