I did. It makes no difference. I even downgraded to a fresh Beta 13, didn't work. I downgraded to Beta 11 even, and did not work.

Calvin

I put in a standard upgrade, I tried beta 13, and beta 11 with no luck. This is *completely* fresh. I ried ethernet, usb and serial. No luck. Doesn't sync.

Calvin

Was this ever resolved?

Stu

Not yet. I'm going to attempt to sync from a different computer this week. I'm still in the process of moving all my stuff from my ex-employer back home.

Calvin

[screenshot of error 0xc0041010]

Errors of the form 0xc0041??? are errno values being reported from the player. The ??? is the errno value, here 0x10 or 16, which is EBUSY. That error typically results from trying to unmount a filesystem that still has a file open on it. I know you've said there's nothing custom being run on your player, but nothing in the Empeg software should be holding a file open at that stage.

As it's obviously running fsck (the "no such file or directory" errors are indeed benign), the failure must be in remounting the filesystems afterwards.

Could you send me (peter@empeg.com) an emplode log of a failed sync, please? (You can turn on logging in Emplode in Tools->Options->Troubleshooting.)

Peter

After a spate of computer problems I finally got around to attempting to sync to my empeg from a completely different machine and I get the exact same problem.

Calvin

It's wednesday now, and I'm starting to get a little worried. :-( I haven't heard anything new from empeg support, and I haven't been able to sync music for a while now. :-(

Calvin

And you're absolutely sure that you've blasted a fresh beta13 onto the player, and not changed the default software in any way after the software installation, and the problem still happens?

Or are you still using a modified init?

Absolutely. I put a completely fresh beta 13 with NO changes and found the same error occured. I then put on a completely fresh beta 11 with NO changes (directly off the empeg support site, using the upgrade tool). This meant all the third party stuff was nuked off the system. I found that even beta 11 did not work so I concluded that the bug had nothing to do with version, and I then reloaded all my third party software (hijack, web site, etc) and still have the same error. Then on the off chance that perhaps the error was occuring because of a problem in the computer emplode was on, I installed emplode on a fresh computer and still have the same problem. Jemplode also has the same problem.

Calvin

have you tried to delete the database and recreate it? or just rename it at least, because if it doesnt work even after that.... no more music til we figure it out

I haven't done that, because what if emplode refuses to rebuild it? Then I will be out an empeg! At this moment my empeg works, in the sense that it plays and does everything it's supposed to... except sync. :-(

Calvin

thats why i said just move/rename all the files instead of actually deleting it.

I'll put it on the list of things to do. *sigh*

*crossing fingers*

Calvin

Just touching this thread again. Still waiting.

Calvin

If it happens from multiple clients, I don't know why you expect anything short of moving the database out of the way and rebuilding is going to help you.

That said, what are you waiting for?

And incidentally, what does /etc/fstab on the player contain? Better if you can attach the actual file rather than copying and pasting, but whatever.

I'll put it on the list of things to do. *sigh*

Have you tried this yet? Basically, something on the player (and as there's no 3rd-party stuff installed it must be our player software) is holding open a file on the music partition, which means the media check can't go ahead. The most likely type of bug that would cause this, would be some kind of bug in the database loading such that it failed, but left the file open. Renaming all three database files (database, tags, playlists) out of the way and rebooting, so that the player isn't loading any database files but is rebuilding the database on startup, would fix the problem if this is the case.

If, after doing this renaming, you can successfully synchronise, I'd like to see the original database files that caused the problem. If, after doing the renaming, you can successfully synchronise once and then the problem comes back, I'd like to see the new database files too!

Sorry I haven't got back to you until now, but we're all (a) very busy and (b) stumped!

Peter

No problem. I'm am trying this now! You guys are the only big company that I have patience for. ;-) brb.

Calvin

#
# /etc/fstab
#
# <device> <mountpoint> <filesystemtype> <options> <dump> <fsckorder>
/dev/hda5 / ext2 defaults,ro 1 1
/dev/hda4 /drive0 ext2 defaults,ro 1 1
none /proc proc defaults

Where are the database, tags and playlists files located? I never had to mess with those before. I assume I have to repeat this for both drives?

Calvin

/drive0/var

Here's what happened. I renamed the files to database.old, tags.old and playlists.old. I set the disk to ro, then rebooted. Upon reboot it rebuilt databases. Then I ran emplode, and it ran down the list:

Initializing (check)
Connecting to player (check)
Getting player version information (check)
Checking database (check)
Checking media (X) (failed) -- Error 0xc0041010.

argh! :-( as if it can not get any worse, now it is worse. Before, I was able to connect to the player and view all the contents and playlists and click on items and "play" them remotely. Now opening emplode induces a "building database" on the empeg, and when that fails nothing opens up in emplode. oh crud. :-( I'll see what happens when I put the .old files back.

I'm on the player, (via telnet) and there are no database, playlists or tags file. Just the ".old" ones. Looks like it was simply not rebuilt??

Ok, restoring the .old files back fixed things back. Emplode can now read the database again. Back to square one again.

Calvin

Um. Hmmm. Did you ever send us your fstab?

Also, got strace for (on) your player?

Actually, the earlier errors scream that you have no /drive1 entry in /etc/fstab

Mine is:
/dev/hdc4 /drive1 ext2 defaults,ro 1 1

I'm on the player, (via telnet) and there are no database, playlists or tags file. Just the ".old" ones. Looks like it was simply not rebuilt??

Yes. Gosh. There must be something in your *1 files that the player really doesn't like.

Ok, restoring the .old files back fixed things back. Emplode can now read the database again. Back to square one again.

OK, could you email me (peter@empeg.com) those three database files, please?

Peter

I added the line to my fstab, and the sync process still fails with the same result.

Peter has also determined my database files are OK. Nothing wrong with them. I have further steps and todos to look into. So far no progress. I'm going to remove hijack temporarily to test a few more things and will see if it helps. :-(

Calvin

Yes.

aftyer you added the line to fstab, did you reboot?

and actually, log into the player, umount /drive1
then ls /drive1

is there stuff there? if so, mount /dev/hdc4 /mnt
and then move everything from /drive1 into /mnt
umount /mnt
and reboot.

aftyer you added the line to fstab, did you reboot?

Nothing on the player actually uses /etc/fstab, not even fsck. The /etc/fstab on fresh-from-Empeg upgrades doesn't, in fact, contain a line for /drive1. Fsck scans /proc/mounts if you pass it a mountpoint. And anyway, it's not fsck that's failing; umount(2) on /dev/hdc4 (which the player does before spawning fsck) is giving EBUSY.

and actually, log into the player, umount /drive1
then ls /drive1

He did this upthread somewhere. Nothing's in there.

Peter

Is it an empeg feature that his kernel boot log indicates that the second drive is /dev/hdb, while everyone in the thread is talking about /dev/hdc. I don't have two drives to verify, but to me this looks like it could be caused by a mk1 image that was installed on a mk2 player.

In any case, ps (or better lsof) could be used to see whether any unusual processes are running that have open filehandles on /drive1.