Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#234049 - 20/09/2004 12:02 Annnnd jEmplode 64
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
OK .. This is probably the largest single update in over a year. That's good and bad ... Good because there's a lot of cool stuff in there, bad because nothing may work anymore I'm curious about:

1) soup performance -- does the app feel substantially slower? (there's a LOT more stuff going on behind the scenes now to do dynamic rollups, resorting, etc)

2) success/failure of fast db rebuilds

3) messed up soups ... soups were rather dramatically modified, so keep an eye out for weird problems and exceptions on the console

I recommend dropping all your soups before you upgrade and readding them afterwards ... At the very least drop and readd after the upgrade, but having a clean soup-slate going into the new build will just make it happier I think.

And for the changes:

Option to disable removing articles for comparisons (look in Options menu). You will need to drop and readd your soups for this to function properly in your soups (it won't retroactively update)

Regex search (title regex "^[a-z]")

Track numbers are sorted numerically (actually, the same comparison is used in soups as in table column sorting, so dates are sorted properly as well)

Empty fields are left empty rather than setting to "(none)" .. a bunch of (none)'s just looks busy

Option to enable Tony Selections

Rebuild-on-PC is back (check Options panel, off by default). This currently requires a 3.0 player because it writes an /empeg/var/database3 file.

Fast rebuild from memory is back (check Options panel, off by default). Note that Rebuild-on-PC is actually pretty damn slow .. Fast rebuild's where it's at. All the cool kids are using it. Oh yeah, pc rebuild and fast rebuild are both alpha. It's not a big deal, since worst case is your Empeg just forces a rebuild, but you've been warned.

Reordering of soup playlists when aggregate tags change

Fixed problem in rebuild-on-pc where the Empeg would timeout and restart before the rebuild completed

Fixed problem in rebuild-on-pc where a bogus tag (line w/ no = in it) would explode the rebuild and fall back to the on-Empeg rebuild

New Playlist brings up an RMML-style fill-in-title box first that gives you the option to cancel playlist creation

Added aggregate tag support/updating aggregates to all playlists (not just soups)

Year is sorted as a number

Playlist checkbox properties actually do something more than look pretty again ... actually they don't even look pretty ... oh well .. they work now

New Sort By Tag pulldown in the Playlist properties dialog tab. This sets and maintains a running sort of the playlist. If a child playlist is created it inherits the parent's sort by default, but this can be overridden.

Global autosort property is gone now since you can control it on a per-playlist basis. I might bring this back as a new default sort, but we'll see how people end up using the new soup sorts to see if this is even useful.

Runtime loop checking is done on playlists now (so you can't put Playlist A into Playlist A and various other permutations of that problem)

Top
#234050 - 20/09/2004 12:06 Re: Annnnd jEmplode 64 [Re: mschrag]
Daria
carpal tunnel

Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
Quote:
Fast rebuild from memory is back (check Options panel, off by default). Note that Rebuild-on-PC is actually pretty damn slow .. Fast rebuild's where it's at. All the cool kids are using it. Oh yeah, pc rebuild and fast rebuild are both alpha. It's not a big deal, since worst case is your Empeg just forces a rebuild, but you've been warned.


This did happen to me once, and that day, I wished I'd had a menuexec item on the empeg to put the disk in rw mode so the database would be written.

Of course I'd rather patch hijack to provide it because the builtin rw/ro functions that the ftpd uses as site commands are faster than the unedited rw/rwm scripts.

Top
#234051 - 20/09/2004 13:58 Re: Annnnd jEmplode 64 [Re: mschrag]
cushman
veteran

Registered: 21/01/2002
Posts: 1380
Loc: Erie, CO
Thanks very much Mike, will use/test later this week after I return from a trip.
_________________________
Mark Cushman

Top
#234052 - 20/09/2004 19:53 Re: Annnnd jEmplode 64 [Re: mschrag]
mcomb
pooh-bah

Registered: 31/08/1999
Posts: 1649
Loc: San Carlos, CA
So, I'm confused by the difference between "Rebuild on PC" and "Rebuild from Memory" how are these different again and do I want to check one or both of them? I tried just from memory since you said it was faster, but it didn't seem to make a difference.

-Mike
_________________________
EmpMenuX - ext3 filesystem - Empeg iTunes integration

Top
#234053 - 20/09/2004 19:59 Re: Annnnd jEmplode 64 [Re: mcomb]
mcomb
pooh-bah

Registered: 31/08/1999
Posts: 1649
Loc: San Carlos, CA
Quote:
I tried just from memory since you said it was faster, but it didn't seem to make a difference.

Got it, checked both of them and the rebuild took like 2 seconds on my dual G5. Very nice
_________________________
EmpMenuX - ext3 filesystem - Empeg iTunes integration

Top
#234054 - 20/09/2004 20:04 Re: Annnnd jEmplode 64 [Re: mcomb]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
There's actualyl rollovers on the labels for them ... It's basically a terrible UI, but by the time I get to adding options to that options panel I just want to go to sleep

So Rebuild-on-PC means that you want the computer to construct the database and send it over. Only checking rebuild-on-pc means it will do it the "safe" way, which is to enumerate all the FID files on the Empeg one at a time, loading the tags in and building the db file. This is REALLY REALLY slow. I'm not sure there's even any value in keeping that implementation at all actually except that maybe someone could come up with some clever optimizations (some sort of hijack interface where it will stream all the FID files concatenated together).

So Fast Rebuild is a variation on Rebuild-on-PC -- in fact it requires that you turn on PC rebuilds also. Instead of downloading the tags from the Empeg, it takes advantage of the fact that it already has the entire database in memory and just vomits it into the Empeg database format and ftp's it over. It's REALLY fast. The catch here is that if there is some wacky problem, like jEmplode is out of sync or who knows what else, you might get a wacked database. It's probably pretty safe though. And worst case is to blow about the database and just let the Empeg rebuild.

Top
#234055 - 20/09/2004 20:23 Re: Annnnd jEmplode 64 [Re: mschrag]
mcomb
pooh-bah

Registered: 31/08/1999
Posts: 1649
Loc: San Carlos, CA
Quote:
There's actualyl rollovers on the labels for them ... It's basically a terrible UI

Well, hey look at that. I never hovered long enough to get them I guess. The finicky part is the levels of interdependence. A less terrible UI (your words not mine ) would probably check "PC Rebuilds" and "Use Hijack" for you if you select the in memory builds.

-Mike


Edited by mcomb (20/09/2004 20:23)
_________________________
EmpMenuX - ext3 filesystem - Empeg iTunes integration

Top
#234056 - 20/09/2004 20:25 Odd bug w. jEmplode 64 [Re: mschrag]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
When editing or adding to a playlist in the root directory, I noticed the Artist, Source and Year fields for that playlist had all been set to "Various" rather than left blank. Any contents from that folder/playlist were then dumped from that folder into the root on the next sync because their ref counts had all be set to 0 during the sync.



Also, creating New Playlists do not work either....

FInally, I was able to copy tracks from one empeg to another, but I could not click on an entire playlist and copy that from empeg0 to empeg1.

I used Jemplode 61 mainly for updating HiJack via ethernet, so I'm not sure if 64 is the cause.


Attachments
233296-various.gif (154 downloads)



Edited by SE_Sport_Driver (20/09/2004 20:50)
_________________________
Brad B.

Top
#234057 - 20/09/2004 20:30 Re: Odd bug w. jEmplode 64 [Re: SE_Sport_Driver]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
I have another one... (related?)

When trying to drag a folder into Jemplode or do a "New Tune Directory" I get the following error.


Dragging the individual files works fine.


Attachments
233299-Clipboard01.gif (193 downloads)



Edited by SE_Sport_Driver (20/09/2004 20:34)

Top
#234058 - 20/09/2004 20:33 Re: Odd bug w. jEmplode 64 [Re: SE_Sport_Driver]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31602
Loc: Seattle, WA
You gotta open the attachment now to get a proper URL, can't just copy the attachment link any more.
_________________________
Tony Fabris

Top
#234059 - 20/09/2004 20:34 Re: Odd bug w. jEmplode 64 [Re: tfabris]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
Thank you!
_________________________
Brad B.

Top
#234060 - 20/09/2004 20:58 Re: Annnnd jEmplode 64 [Re: mcomb]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Yeah -- so don't look at that code and you won't have to know why it isn't fancy like that It's just a massive blob of brute force checkboxes and crap. I've been meaning to make a nice set of abstractions for those preferences, but it's just hard to get excited about making the options cool ...

Top
#234061 - 20/09/2004 21:04 Re: Odd bug w. jEmplode 64 [Re: SE_Sport_Driver]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Quote:
I noticed the Artist, Source and Year fields for that playlist had all been set to "Various" rather than left blank

It should be rolling up tags to the playlists now ... Do people prefer blank over "Various" to imply a mix? I went for Various because if you actually had all blanks vs one blank and 9 correctly filled values, you wouldn't be able to tell the difference, vs having an explicit string that means mixed values lets you know for sure what's up (unless of course you have a band called "Various"). Or is there not actually a mix of artists, albums, and genres in that playlist?

Quote:
because their ref counts had all be set to 0 during the sync.

OK yeah that's just wrong ... I'll try to setup this scenario.

Quote:
Also, creating New Playlists do not work either....

Weird -- What does it do? I created several playlists. Can you check your console and tell me what exceptions are there? (you might need to run it java -jar jemplode.jar from a shell)

Quote:
but I could not click on an entire playlist and copy that from empeg0 to empeg1

What did it do you when you tried this? You did a past and it just did nothing?

Quote:
so I'm not sure if 64 is the cause.

64's pretty drastic changes, so I figured it would take a couple builds to get it going right ...

Top
#234062 - 20/09/2004 21:05 Re: Odd bug w. jEmplode 64 [Re: SE_Sport_Driver]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Quote:
When trying to drag a folder into Jemplode or do a "New Tune Directory" I

Very likely the same problem as copying playlists from another Empeg since those are handled in nearly the same code path ...

Top
#234063 - 20/09/2004 21:11 Re: Odd bug w. jEmplode 64 [Re: mschrag]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Crap .. lame test cases .. I have been so focused on sorting that I forgot to test these scenarios WITHOUT sorting enable.

Top
#234064 - 20/09/2004 22:10 Re: Odd bug w. jEmplode 64 [Re: mschrag]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
I'm not too concerned about the "Various" feild, I just assumed it was related since the same playlist was causing the refs=0 problem.

The problems I listed were with my friend's empeg which is now on it's way (with him) to Colorado for a 12 hour trip. That rules out more testing with his player. It did happen twice however and I was able to fix it via emplode.

On my player, I'm not able to recreate the fids=0 issue (I'll try more tonight) but I can confirm not being able to insert folders. In a bit I'll hook up a console output.
_________________________
Brad B.

Top
#234065 - 20/09/2004 22:38 Re: Odd bug w. jEmplode 64 [Re: mschrag]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
Could you put up 62 or 61 so I could see if any of this stuff isn't related to 64?
_________________________
Brad B.

Top
#234066 - 20/09/2004 22:45 Re: Odd bug w. jEmplode 64 [Re: SE_Sport_Driver]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
Sorry to keep piling on here...

I can't get any searches to work.
_________________________
Brad B.

Top
#234067 - 20/09/2004 22:50 Re: Odd bug w. jEmplode 64 [Re: SE_Sport_Driver]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
I actually think all your problems are related to the same thing, which is that a playlist can't be created that is the child of another playlist that is unsorted. 65 is going up mometarily.

Top