jemplode-induced database problems?

Posted by: hybrid8

jemplode-induced database problems? - 26/11/2004 23:57

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
Posted by: tfabris

Re: jemplode-induced database problems? - 27/11/2004 00:20

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.
Posted by: hybrid8

Re: jemplode-induced database problems? - 27/11/2004 01:08

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
Posted by: matthew_k

Re: jemplode-induced database problems? - 28/11/2004 02:56

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
Posted by: frog51

Re: jemplode-induced database problems? - 29/11/2004 13:31

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.
Posted by: zexpe

Re: jemplode-induced database problems? - 29/11/2004 17:11

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
Posted by: jdandrea

Re: jemplode-induced database problems? - 02/01/2005 14:15

Quote:
Anyone else have any odd database issues when using jemplode *and* emplode? ... 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.


I'm having the exact same problem, and repeatedly so. Not using emplode at all either. Here's the setup: jemplode v69.{0*18}1 ;-) on MacOS X 10.3.7, empeg mk 2a, v2.0 final (developer image), hijack v413.

I'll bring in a few new albums and sync. While the player will reboot at the end I still need to quit jemplode and restart. It never seems to detect that the player rebooted and seek it out. Or maybe it is and something's in the way. (On reboot the player does change IP addresses - maybe that's a culprit - at least in terms of finishing the sync from the jemplode side.)

What else can I provide as evidence/info ... howzabout the jemplode settings. Maybe we'll find a pattern in there across the board:
  • Filename and Soup Filename formats: {artist}-{source}-{title}{ext}
  • Hijack URL: http://empeg-hijack.sourceforge.net
  • Hijack Mk Version: mk2
  • Hijack ftp login/password: empeg/*****
  • Hijack save location: /Users/jdandrea/Desktop
  • Use Fast Connection
  • Only Show Failed Imports
  • Autoselect if 1 Empeg Found
  • Colorize playlists recursively
  • Deduplicate on import
  • Import M3U's
  • Strip Articles when Comparing
  • Look and feel: system
Posted by: mcomb

Re: jemplode-induced database problems? - 02/01/2005 19:13

Quote:
I'm having the exact same problem, and repeatedly so. Not using emplode at all either.


Same here, but only when I sync under FreeBSD. When I sync from OS X it always seems to work fine. My configs on the two machines seem to be identical so I always blamed it on the FreeBSD JVM being buggy. Maybe there is a larger issue.
Posted by: Memil

Re: jemplode-induced database problems? - 05/03/2005 20:22

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
Posted by: mschrag

Re: jemplode-induced database problems? - 07/03/2005 15:40

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 ...
Posted by: hybrid8

Re: jemplode-induced database problems? - 07/03/2005 18:08

No soup for me.

Bruno
Posted by: Memil

Re: jemplode-induced database problems? - 12/03/2005 08:52

No soup for me neither...

/Fredrik
Posted by: Memil

Re: jemplode-induced database problems? - 18/03/2005 05:40

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
Posted by: zexpe

Re: jemplode-induced database problems? - 06/07/2005 11:54

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
Posted by: wfaulk

Re: jemplode-induced database problems? - 06/07/2005 12:58

Quote:
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


In addition, if you remove those varables from the advanced(?) panel of the playlist properties and then sync, then those playlists get detached from their container and, on reconnect, get reattached to the root playlist, where you have to move them to their original spots, at which point, all is fine.

That is, if you want to add a new playlist, but not have all that "various" cruft lying around, then it requires three distinct syncs: upload sync, de-"various" sync, reattach sync.
Posted by: toolman

Re: jemplode-induced database problems? - 06/07/2005 22:09

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?
Posted by: toolman

Re: jemplode-induced database problems? - 07/07/2005 00:15

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
Posted by: dmz

Re: jemplode-induced database problems? - 07/07/2005 05:10

Quote:
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


To the best of my knowledge, they are... if you do run into a bug in them (the com.tffenterprises.music.* ones, that is; I can't speak for the other ones), I'll fix it. They're the ID3 parsing/writing classes.
Posted by: zexpe

Re: jemplode-induced database problems? - 07/07/2005 10:23

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
Posted by: toolman

Re: jemplode-induced database problems? - 08/07/2005 02:32

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...
Posted by: zexpe

Re: jemplode-induced database problems? - 26/07/2005 15:13

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
Posted by: Memil

Re: jemplode-induced database problems? - 27/07/2005 17:39

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

/Fredrik
Posted by: mschrag

Re: jemplode-induced database problems? - 02/08/2005 11:32

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.
Posted by: toolman

Re: jemplode-induced database problems? - 07/08/2005 23:31

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