Help!!!!
I ugraded to 1.02rc1 ..... went well. :-)
ran new 1.02 emplode and changed master playlist name and renamed "Unattached items" folder to just unattach. tryed a quick sync and boom - right after the "controlling disk" message I get "Waiting for the empeg-car to respond" while empeg says rebuildiing database.
Progress bar gets to 100% and Error "The synchronisation process failed during stage 5: Error 0xffffffe4" appears.

I must now re-connect to player..... Master playlist gets renamed to the default "empeg-car" and unattached items has also returned back to normal. All my playlists are now gone and have been moved into "unattached items" folder and it's bold. From here on out.... no matter what I seem to do I keep ending up with the same error when I try to sync and all my playlists end up in "Unattached items"

I captured an emplode log starting from a connect to a sync with no changes being attempted. I included the log with this thread.
Just search on "error".

Was it a bad thing that I tried to rename those lists? or is it 1.02rc1?? By the way... trying to reload an older release "1.01" causes the player go into this looping condition of "rebuild database and reboot" and keeps repeating this forever. I have to load and run 1.02rc1 to stop the cyclic reboots. at least from there I can see my playlists in Unattached items, The player will play via emplode from there.

Any help would be most appreciated.
Thanks

12Gb MKII 080000516 Blue

I'm embarassed to say that, even though I tested pre-release betas of 1.02, I never tried renaming my root playlist.

Mike says that the root playlist can be renamed, but I don't remember his release notes saying that the Unattached Items folder could be renamed.

Have you tried creating a single new playlist called something like "All" in the root, then copying the contents of Unattached Items into that playlist, then synching?

___________
Tony Fabris

I renamed Unattached Items in 1.0 without problems...

Frank van Gestel

I renamed Unattached Items in 1.0 without problems...

Hmm, then maybe his problem was renaming Unattached Items and the root playlist at the same time without a synch in between?

And don't ask me to try it. I like my databases the way they are, thank you very much: Functional.

___________
Tony Fabris

Whew... I got a reply from Mike his thread goes like this:

The error 0xffffffe4 means that you have run out of disk space. You must
have been _very_ close to full before you installed the v1.02rc1 upgrade. If
you delete a few tracks you should find that synchronisation succeeds, at
which point you can move everything back out of unattached items.

Believe it or not - this is much better than the situation that used to
occur in previous versions of the software where it would be impossible for
the user to recover from the situation themselves.
--
Mike Crowe
empeg Ltd

He is right I had only about 15 or 20meg free on the disk before I upgraded. in the error condition emplode still reports 20 meg free. but Empeg did state in the release notes that they made changes to better handle full disks. So I will try Mike's suggestion tonite and re-post.
Thanks Mike!


12Gb MKII 080000516 Blue

I've advised "flashman" by email about the problem but I thought everyone might be interested in the cause.

1.02-rc1 (and a few betas earlier) does some better disk full detection. It has a safety margin that is required for rebuilding the database and other stuff. If a player has already exceeded the safety margin when 1.02-rc1 is installed then it will produce disk full errors for most synchronisation tasks - in 1.1 this should be dealt with much more cleanly.

1.02-rc1 had a bug in the disk space detection code whereby it would wipe the contents of the file before checking how much space was available - so, if you renamed your root playlist so that the new name was longer than the old name (or you introduced some new tags that weren't there before) then it would erase your 101 file, decide that there wasn't enough disk space and then give up. When rebuilding the database the root playlist would be ignored since the 101 file didn't exist and everything would end up in Unattached Items.

Needless to say that I've made it check the disk space before it wipes the file and the disk full error now actually says "out of disk space" so that people will at least have a clue to the problem.

I've trashed my root playlist several times today during testing and so far it has just been a simple task of dragging everything back out to the root again. This morning we worked out a better unattached items collection algorithm that should make this even more reliable.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Needless to say that I've made it check the disk space before it wipes the file and the disk full error now actually says "out of disk space" so that people will at least have a clue to the problem.

Cool. I guess that's why public release candidates are still a Good Thing, eh?

___________
Tony Fabris

Wow what panic that whole thing caused me. I am now much older.
I ran emplode in order to erase some files as mike suggested.
This only would fail on sync before the actual erase would commit so emplode was out. To make matters worse the playlist in "Unattached items" was getting mixed up. I tried to delete one album that I did not like. Sync then failed and upon next load.... all albums under that playlist moved to the root but the playlist remained, some individual tracks moved out to the root orphaned. Ok this is not going to work...
I then realized that Empeg just poped out 1.02 RC2 ... so i loaded it. this time the syncs would fail at stage 6 with the error "file not Found". I'm getting scared now... so I read and read alot of posts on using Hyper terminal and the command prompt.
After I loaded 1.02RC2 developer and gave myself a crash course on Unix 101, I was able to delete 3 Fids ending with 0 that were mp3 files and I left the coresponding database record (ending in 1) behind. then remarked Drive0 back to read only. and then SUCCESS!! emplode will now sync without error. It took a little fixing to correct the botched playlists but all is back to norm! Whew!

Now my question. all is well on my player again... I would like to know if i should have deleted the corresponding database files with the actual mp3 files? or will the player figure this out and fix it? I also do not know exactly which 3 MP3s I trashed, can i figure this out with export function in emplode?

Thanks again for all of your help!

12Gb MKII 080000516 Blue

Hmm, very strange. I'd like to have known what the "failures" at the various stages were.

I've found a tiny bug in the emplode code that would cause it to report the error as coming from stage 6 (database rebuild) even though it actually came from stage 5 (synchronising stuff). So the "file not found" error you reported probably came from stage 5. Why this would happen I'm not sure. I don't suppose you have a log file from that attempt do you?

I'm doing some testing now to see if I can fathom what could have caused your problem.


--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

this time the syncs would fail at stage 6 with the error "file not Found".

Bug found and fixed.

If you've got lots of stuff in unattached items due to a bad sync then it is still possible to get disk full errors during synchronisation since emplode won't be able to resync the unattached items playlist to disk. It is now (since above bug fix) possible to delete stuff from playlists since files are allowed to stay the same size or get smaller when synchronising to a full disk.

Also, emplode wasn't necessarily deleting everything before attempting to write stuff so even if enough space was freed up things might have been done in the wrong order so you'd still get a disk full error. This has also been fixed.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Awesome! You were correct again.. I had not moved any of the stuff back out of unattached items after I used emplode to erase some songs. (I felt safer doing one step and hopeing the sync would fly, then I was going to correct the playlists)

I am still curious however, should I have deleted the database Fids that matched the three mp3 files that I deleted? Or will the player correct these orphans? Is there any way I can determine which files I deleted by any method? I wrote down their names.... "FD0, FE0 & FF0"=mp3's their matching files were "FD1, FE1 & FF1"=playlist hooks?

After the good syncs and all the playlists were fixed I deleted (using emplode) an entire album I did not like so I should have enough room to add back the three unknown mp3 files I
waxed.
What will the player do if it encounters a database entry for an mp3 file that does not actually exist on the disk?

Glad I could help you find these nastys and prevent others from getting these in the gold bits... (I love QA testing as it is what I manage for a living at Veritas.)

Thanks again sir!!!
Empeg support is Awesome.

12Gb MKII 080000516 Blue

I am still curious however, should I have deleted the database Fids that matched the three mp3 files that I deleted? Or will the player correct these orphans? Is there any way I can determine which files I deleted by any method? I wrote down their names.... "FD0, FE0 & FF0"=mp3's their matching files were "FD1, FE1 & FF1"=playlist hooks?

You should have probably deleted the 1 files too. I know that the other way round doesn't cause any trouble (i.e. a 0 file with no 1 file). I've checked the database rebuild code and it doesn't ignore entries without content. What will probably happen is the player will just go into pause when it would have played the track and you'll need to skip track to get it to play again.

The easiest thing to do is go in and delete the fd1, fe1 and ff1 files then download again to emplode, references to the deleted items will then be removed from the playlists when you resync and everything should be fine.



--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

In reply to:

---

Is there any way I can determine which files I deleted by any method? I wrote down their names.... "FD0, FE0 & FF0"=mp3's their matching files were "FD1, FE1 & FF1"=playlist hooks?

---

If you still have those FD1, FE1 and FF1 tag files, simply read them, they are plain ASCII. Connect a terminal to serial port, type q (enter) once or twice to quit the player, then, from the shell prompt:
cd /drive0/fids (or /drive1/fids)
cat (tag files)

Hm, but you will know this (except perhaps about *1 files being ASCII) - you made room on your disk by deleting files manually. Anyway, let this stay, some novice will perhaps find it useful...

Cheers!


Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green