For the second time in a row, when I tried to synchronize with Emplode, the process blew up with an error. Clearly, something is wrong here.

"Synchronize failed while writing player configuration. An existing connection was forcibly closed by the remote host. (error 0x80072746)"

At least this time I was smart enough (thanks, Tony F.) to leave things alone until the player timed out and went back to RO on its own, so it boots up and runs properly. (Last time I had to do a manual fsck and manual database delete and rebuild to make it work.) And everything that was in the upload to the player seems to be in place.

I am running a dual 80-gig player with 2.0 final release software, HiJack v413, with 1704 playlists and 13,174 tunes.

Any ideas what might be causing this?

tanstaafl.

13,174... I think you might be approaching that magic number where you should look into patching your player to allow large FID counts... See this thread for the binary (version 7).

True, that is one aspect. But another is that it allows you to have fids beyond the hard coded limits on the default player app. Once beyond that maximum, one of the first symptoms you see is that sync fails. You are able to upload the new files to the player, but the database rebuild will crash through emplode, and you have to rebuild the database manually.

I have not tried it with ethernet, so I am not sure the specific error number or if Doug is seeing this problem specifically, but the description seems very similar and the fid count (tracks + playlists) seems close enough to give the patch a try.

Read the thread below... it sounds like you are having the same issue I had. Run set_empeg_max_fid.v7 and things start to work again

This Thread

13,174... I think you might be approaching that magic number where you should look into patching your player to allow large FID counts... See this thread for the binary (version 7).


Thanks, Paul (and you, too, Jemmi) - that seems to have done the trick. It was a bit of a rocky road getting the player to talk with emplode, but after several reboots and a few abortive synchronization tries, it all began working just fine.

tanstaafl.

Hi All,

I'm now getting this exact same problem. I see that it seemed to have been remedied by the maxfid patch, but I JUST did that, and I'm still getting the problem. After emplode crashes, my player continues to say that its syncing. I have to leave it alone for a long time and it will eventually work itself out...

Any other ideas?

- Thanx
- Jon

I'm not convinced that Doug's emplode-crashing problem had anything to do with maxfid or the number of tracks in his player. Not with only 13,000 tracks.

I think there are a few different issues that arise with large numbers of tracks, and Maxfid only worries about one of them:

a) Number of tracks that can be saved to the dynamic data partition when you select a playlist. Maxfid increases the number of entries that can get written to the dynamic data partition, so that you can play larger playlists and have the player remember your playlist position across reboots.

b) Size of the empeg's internal song database, and how much RAM it takes up when loaded into memory.

c) Ability for the player to perform a database rebuild during the synch process without running out of RAM and crashing. (Related to b, above)

As far as I know, Maxfid doesn't handle cases B and C. Assuming you're not having any disk or filesystem trouble, I'd bet you're runing into C.

I think (not certain) that one way to help control B and C would be to reduce the number of characters in the database by making sure the comment field is empty for all tracks.

Can you try having an open hyperterm (capturing the session) while trying to sync via USB (or ethernet)? This way, any kernel error messages from a memory error or program crash can be captured and reported.

If you are running out of memory during a database rebuild, there might be a way to fix it - by turning on the swap before syncing. This might be rigged either with a hijack program run when connected to AC (you do not want swap on while in the car, I assume), or manually doing:

q #drop to shell
swapon /swapfile #turn on swap
exit #exit shell
#sync with emplode

Ok, I just tried to do a sync with no file transfers. emplode crashed at the end, but the player didn't go into a synchronizing tizzy either, and the hyperterm looks normal (to me). See attached.

I'm gonna do it again with some mp3 uploads...

- Jon

Ok, just re-did it, but this time, also uploaded an album. After a long re-build, and after the player re-started, emplode crashed. It's a different crash then I was getting earlier, with the "Synchronize failed while writing player configuration. An existing connection was forcibly closed by the remote host. (error 0x80072746)"
message. This is just a crash. The player didn't go into the sync tizzy again this time.

I've attached the log.

Am re-doing it with debug turned on...

- Thanx
- Jon

Of course, with debug on, emplode didn't crash... Grr.

- Jon

I hate when that happens...

But, try it without debug. Perhaps it has cleared the problem? (Worth a shot...)

Ok, got a failure. See attached debug. Seems like it can't see the empeg after it reboots...

Any ideas?

- Jon

Hmmm... Okay... I am not really sure what more to recommend.

You said that if you let the player sit long enough, it finishes the sync and database build without errors. Is the database complete? (Does it have to rebuild the database on reboot, or just load it?) If the database is okay, I can only guess that emplode is timing out waiting for the database to be built. Have you ever done a fidsift?