Anyone else have any odd database issues when using jemplode *and* emplode?

The problem I just had is detailed below. Unfortunately there are a bunch of steps so I can't pinpoint the problem...

A few days ago I used jemplode to change my main playlists. I emptied out (and removed) two playlists that contained my various artists lists. I made 18 or so smaller lists to put all the artists in to. Synced and everything was fine for a few days.

I upgraded my primary hard drive, swapping out a 30GB IBM for a new 100GB Seagate. Copied all fids and dynamic data partition. Did a couple of syncs in emplode and everything was still fine. Last night I added a few tunes to the player and removed a few as well. Left it syncing over night.

This morning I noticed that down down down didn't give me all my tracks. Reloaded DB in emplode to notice that a large number of artist playlists (with album nested lists) and some individual album playlists were in the root instead of their proper parent lists. The playlists were in fact unatttached and that's why they were showing up under the root.

Using jemplode I fixed the layout by putting those playlists where they're suppposed to go. Did a sync that said it was successful. Only to find the same problem again, but not with all the same playlists. Some stayed where they were supposed to be, but not the others. Did the same thing with emplode (moving the playlists into proper parents) and did a sync. This time it all took and everything seems fine.

Any ideas?

Bruno

Is player firmware version 3.0 alpha involved in any of the above equation?

The behavior you describe, I've seen intermittently with 3.0 alpha, regardless of Jemplode or Emplode.

Sorry, forgot to put the version in the message... 2.0 final with hijack 413.

It wasn't that big a deal, but when it first happened it scared the living daylights out of me. When I saw the word "unattached" I wasn't paying too much attention and then thought all those root-level playlists were empty. Once I found they were complte, but just in the incorrect place, I calmed right down. I'd like to continue to use jemplode (because I can use it from my Mac), so I hope this was all just a fluke.

Bruno

I had what I suspect is the same problem while teaching my mother to use jemplode on their central this weekend. Created a playlist, put some things in it, went down to play it and it wasn't there. (Well, it was available for editing on the central, but didn't even show up after edited) I reconnected with jemplode and it told me it reattached an unattached playlist, so I resynced and everything worked fine. We created a few more playlists that worked fine the first time.

I was going to write this off as wierd central bug, but perhaps it's not so isolated.

Matthew

I have had this twice with 2.0final and h413. All my playlists under P and R got stuck in root after trying to alter ID3 tags and synching in jemplode - had to use emplode to fix it both times.

Yep, I've had similar problems with the latest version of jEmplode. Once, maybe twice, before I've altered some details in the database. Resynced. And then found that for one of my playlists all of the sub-playlists had become unattached for no apparent reason, and so on the next resync jEmplode moved them to the root playlist. Very odd.

Ross

I'm having the same problem here. Using 69.000001, didnt have this problem with earlier version (dont remember which I used before I upgraded a couple of days ago. But I remember it was the older startup-logo with the dog. 56 sounds familiar...

I'm not using emplode, just jEmplode in linux...

/Fredrik

Do you have any on-Empeg soup playlists? This went through a major rewrite in the past few versions and would be my first guess as the culprit ...

No soup for me.

Bruno

No soup for me neither...

/Fredrik

I've used v65 now a couple of times, the problem doesnt seem to exist there.
Hoping this could help narrow down the bug...

/Fredrik

Mike,

If you ever have time to fix jEmplode this must surely be the most vital bug fix of the lot! It's getting so frustrating now. For example, today I uploaded two new albums to my empeg using the "select directory" method to create a playlist from the directory name, fill the playlist with the mp3 files under the directory, and place it as a child-playlist of my individual artist playlists. I also copied the two newly created playlists to be child playlists of my "New Albums" playlist. It appears to work fine after syncing (from jEmplode's perspective - I guess things must be messed up on the player), but after reloading the music database in jEmplode, a download error window appears showing that every child playlist in my second artist's playlist is unattached - all three albums including the newly uploaded album, plus a few single tracks. jEmplode reattached the two older albums to the root playlist, but there were no errors regarding the new album playlist or the single tracks as they were referenced elsewhere.

This only happened for the second artist - the first artist's playlist kept references to both it's old albums and new album.

Not only is this very annoying, but it could lead to my database being messed up if I forget how everything was laid out prior to jEmplode's random detachment of nodes.

Also, very minor bug, and it's been noted before, but the new playlists don't take the artist, album, genre, year etc. values from the tracks as previous versions of jEmplode did, but instead default to various regardless of the fact that the attribute values of tracks in the playlist are all the same.

Anyway, I suspect this is a really simple bug to fix, and as it's a real pain I thought I should bring it up again!

Thanks,
Ross

Yep for the record, I have the exact same experience: (that of subfolders being detached and put in the root folder, and I think files ending up with ref=0 too)

I use both emplode and jemplode, and some have suggested that its using both that does it. happened on both players, both run 2.0 developer final (ie non beta) and hijack 417+.

Has happened in jemplode in both windows(sun 1.4.2.something, XP) and linux (sun java 5.0_03, ubuntu ).

I do have large-ish hdds (toolpeg 2x60, grillpeg 60+10) and I saw a post about a patch for large music sets - something to do with the largest fid value available? So yep - bug neeeeeds to be fix cause i have to boot in to xp to sync

Has anyone got emplode going under wine or similar? does it work from within vmware or similar?

Hmm, being a java programmer I have downloaded the source (69.00000001). Seems the source tree is missing 2 imports:

import com.tffenterprises.music.*;

import com.rio.protocol2.PearlSynchronizeClient;

the com.rio one looks like it might be a factory library lifted from somewhere. Anyone got any ideas?

Edit: found the classes in the jemplode JAR and Daniel M. Zimmerman suggests that the source for these are not available. Hope they are bugfree

It's exclusively a jEmplode problem. I only use jEmplode as I don't have a Windows PC. The bug appeared either in v69 or shortly before, perhaps about the time Mike rewrote the soups, though it doesn't appear to be soup related.

For the record I'm using v2 final software, with HiJack v413, emphatic, and jEmplode v69 (and a bit).

Oh, and I *do* have some rather large FIDs! Check out this thread! Mostly due to having multiple soups on my empeg covering each of my songs several times over!

Ross

Ok, so can anyone vouch for a version that doesnt exhibit this behaviour? I see a mention of v65 but not a daily user. And does anyone know who owns the source tree? is it dmz? i can uncompile a previous version if needed, but the original source will be easier for comparison...

Well, v56, was definitely the most solid version I ever used... and I've reverted back to using it now. Haven't tried out v64 onwards yet to see whether they suffer from the same symptons, which are all that are available on jempeg.org. I can e-mail my copy of v56 if it's useful - but I guess there's a lot of changes between that and v69 & a bit!

Ross

I've used v65 now atleast 20 times without any trouble.
So this one is probably free from this bug...

/Fredrik

v56 to v69 contained a major rewrite of the soup system. Architecturally it's a lot nicer, but it was just really bad timing, because almost immediately after the huge rewrite, I switched jobs and got REALLY busy. Basically what everyone is seeing is your typical bugs from a big change that just didn't get the necessary love from QA.

Noticed that JEmplode has gone to v70, so looks like someone might have fixed this problem - anyonce care to comment either way?