Hi All,

Just tried to synchronize some changes to my config.ini (first time I've tried this), and I get the error:

Synchronize failed while checking media.
Error 0xc0041010

Does anyone have any idea what this means?

There doesn't appear to be any problem with the drives, as they pass a manually launched fdisk okay.

I am running 2.0beta7 with Hijack kernel 167

I am going to try a vanilla 2.0beta7 later today, to see if this has any effect.

Any help appreciated.

Andy.

I'm having the same problem, just different error. I've has this problem with v.102, 1.03, and beta 2.00-7. I'm gonna format the drive as soon as I find the proggie to do so.

If you really do need to start from scratch then the drive builder is here:

http://www.empeg.com/cgi-bin/display.cgi?section=downloads&id=5

However, I would suggest that you make sure you have tried everything else first and emailed the support guys before doing it, it is a fairly drastic step.

Well I have no music on the rio anyway. I just got it and it won't work. So I don;t think it would do any harm right?

Well sort of. It's just that you shouldn't normally need to go to such lengths with a new player. I would personally want to find out what had gone wrong first, otherwise you run the risk of the same thing happening again.

True. I fixed the first non booting problem. Swapped spots on the hd cable. Booted up fine. Reformated the rio and now syncs fine. Is it faster uploading Via USB or 10baseT

Ethernet is twice as fast as USB (approximately).

Bruno

I just started getting this out of the blue after having put about 15 GB on my 20 GB player. I've been playing it alot and haven't had a problem until now. fsck says:

##### BEGIN PASTE ########
sh-2.03# fsck /dev/hda
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda is mounted.
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

## End Paste ####

Any ideas? I hope I don't have to wipe this thing out inorder to ever synchronize again. It still playes the existing files without a problem.

First, you shouldn't be fscking /dev/hda. You need to be fscking /dev/hda4. Second, don't do it on a mounted filesystem. There's some more related info in the I got an error message about 'e2fsck' at the shell prompt FAQ.

Thank you, that was very helpful, however, I still have the problem after performing the actions in the mentioned above. I notice that JEmplode says "Media Check failed" after the cosole says:

e2fsk 1.19, 13 Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda4 is mounted

is this normal?

That seems odd. Does your player work at all? Do you have a /drive0 directory and a /dev/hda4 device node?

Yes, the player works fine, there is a /drive0 and also a /drive1 directory.

I have emptris, empacman, and telnetd on /drive0 all starting up using preinit.d withour problems. Using the latest Hijack kernel (from this past month).

I would not know that there is a problem if the sync from J/Emlpode did not work.

Does it take a long time to boot? Like more than ten seconds or so?

No at all - and from the console (serial) there don't appear to be any errors on boot up (except for the mounting attempt of hdc4 which I have not yet installed).

I'm at a loss. Anyone else want to pitch in here?

Hmm. Any of those user apps (emptris, etc.) running while the sync is going? Those have been known to cause problems if you sync when they're running. Doesn't look like that's what's happening here but it seems to be a common problem...

I thought of that and got rid of them in the preinit and it still gave me the problem. Does anyone know what the ext2fs check problem is?

Does it take a long time to boot? Like more than ten seconds or so?

Do you mean to say your player will boot up in 10 seconds?

When I first got my Mk.II, it booted in eight seconds. As more music was added and as subsequent software revisions came out, the boot time slowed, to the point where now it takes 15 seconds.

If I could get back to even 10 seconds, I would be happy.

tanstaafl.

From the time I plug it in, it takes in the neighborhood of 10 seconds. That has always been the case.

Well, I meant way more than ten seconds. I don't honestly know how long mine takes to boot now, but it's in that neighborhood, which encompasses both eight and fifteen seconds. Usually, I'm too concerned about running over cats and avoiding my neighbor's too-closely-parked car to notice how long the empeg takes to boot with any precision.

I found the solution, and even though I'm a little embarrased to admit it, I'll write it here for posterity.:

It was the telnetd deamon. When I removed it from memory, my syncing went fine. Does anybody know why the telnetd would cause this issue?

It's possibly taking up too much memory, but I doubt it.

Probably it was preventing a remount because it had a handle on that filesystem. I'll bet the binary's on your /dev/hda4, isn't it? Try moving it to /empeg/bin, for example, and see if you still have the same problem.

i just discovered another reason for this error occurring: Hijack. Or rather, Hijack still having files open because someone is streaming or downloading an MP3 off of the empeg. Normally, when the player application is closed all MP3 files are closed too, but since the Hijack HTTP server resides in the kernel and is still running while a sync is going on, it is possible for MP3 files to still be open and prevent the disk from being unmounted...

/Pepijn