More and more on the BBS, I'm seeing people recommend JEmplode in favour of emplode. This concerns me.

So, I'm going to ask a simple question:

What features are in JEmplode that, if added to emplode, would cause you to "come home"?

Obviously, OS portability is not gonna happen any time soon, but what else?

The Rules (tm):

1. Replies should contain up to 5 items per person, ordered by desirability.
2. No promises that I'll have time to work on these features.

1. Upload speed
2. Stability
I was burned two or three times in the past (could have been beta 11, don't remember) when emplode had a communication error and promptly discarded all the tag & playlist work I'd done for a half hour. Jemplode seemed more stable at the time, and I've used it since.

Primarily upload speed though.

-Zeke

1) Ability to set the time on the Empeg from the computers clock.

Roger,
addional reason:

Automatic Hijack update

bye

I'm trying to work out just why that concerns you that much (aside from pride in one's creation)

Emplode handles the supported functionality of the empeg well, and although there are a few quirks, I can't see any major improvements that are needed...

But JEmpeg (I believe it got renamed) handles some of the third party stuff developed here - eg hijack updating, boot logos/animation updates etc, that I can't see you supporting officially in Emplode. And the portability is a big issue for a small percentage of us...

One feature that JEmpeg has that I really like is the faux on-empeg-soup playlists. But it is a bit of a kludge - the playlist soup definition is not stored on the empeg at all, but in JEmpegs rc file. As far as Emplode woud be concerned the playlist would be static. And ditto if you used JEmpeg on another machine. But in terms of usability it does work very well.

I'm trying to work out just why that concerns you that much (aside from pride in one's creation)

Round here, that's usually enough

Peter

Round here, that's usually enough

Hey, you can't spell empeg/riocar without e-g-o.

the definitive thing that got me turned over is the ability to get the soups into the RIO. it's an awsome feature. i am also hoping mike will put in a sync capability so i can maintain my harddrive and computer music synced up.

all the other stuff everyone mentioned is nice too.

-ted

Soups on the empeg! (I don't care if it's via emplode or player software. Same end result.)

Soups on the empeg!

Didn't I explain previously that this was a bad idea?


(for what it's worth, it was corn chowder from the Pittsburgh Deli Company, something I usually manage to get for lunch on Tuesday)

If you want to blow JEmplode away and be a hero think replication. If a change is made to the player or the PC they would both be updated on a sync., including playlists.

Advantages:
«» Your PC would mirror your player at all times, i.e. a backup of your player.
«» A user would not have to perform duplicate tasks to keep the PC and the player in sync. Example - Deleting a song on the player and then finding and deleting the song on the PC.
«» Could be used as a tool to synchronize multiple players. They would all look like the PC.

Replication could be an option to the normal uploading. Hopefully this would not be too hard as you can download and upload now.

Replicating tags would also be great! But probably not doable (read...., challenge)

Roger, I'm going to be completely honest:

I do not use Jemplode for most of my player maintenance. Mainly because some of the Java user interface quirks bug me (nothing Mike can really do about that).

However, there is one thing that I must use Jemplode for every single time, and that is for downloading files from the player. Reason: Configurable file naming on download. It is critical to me that I be able to name the files with a carefully-formatted set of file names so that I can run a filenames-to-tags pass on them with Tag Studio. It's the only way I can recover any emplode-edits to tags on the files on the player.

If emplode were able to optionally write corrected V1 and V2 tags back to the files when downloading, then it wouldn't be an issue and I would happily use emplode for this task.

Tony's recommendations re:Tag Writing and downloading are about the biggest things I can think of right now for Emplode. Oh, apart from the bug fixing you're likely doing on a regular basis.

I'd also love to see something Roger has discussed before, and that's some type of scripting ability to do batch operations. Such as batch edits on tags for instance.

I've recently found that part of my PC-based mp3 back-up drive was corrupted at some point. I know a number of songs have been mangled because of this. Rather than re-rip (because I'd have to find out which songs were affected), I'd like an easy option to clone the contents of the empeg back to my hard drive. As well as naming, I'd really appreciate the ability to have playlists created as folders. Of course both the renaming and folder creation can also be handled after-the-fact with something like Tag Studio.

Oh.. And I still use Emplode. I've used Jemplode in the past, but haven't updated nor used it in quite a while. I'm not a huge fan of the java-esque interface elements.

Bruno

On a related note, I'd like to see the Linux empeg tools be not Linux- or endian- specific. I'd also like to see it build a emplode protocol library (which it may already, since I don't have a little-endian Linux machine, so I've never successfully built it) so that a Perl or Python or Ruby or Tcl or whatever module could be written for it.

What features are in JEmplode that, if added to emplode, would cause you to "come home"?

I don't use Jemplode... but would switch over to it in a heartbeat if it had one feature I have been requesting for years:

Give me a one-click full backup! I want to click on an icon, and have emplode or Jemplode or whatever create an exact image of my player on my PC's hard drive -- an image that I could use to do a full restore (music, playlists, metadata, database -- everything!) onto my player. Even if the only thing I could do with that image is restore it onto the same player that created it (I don't need to read the image file, play the image file, modify it, copy it to another player, or anything else) that would be enough.

tanstaafl.

I don't use Jemplode. Actually - after the Cinci meet - I decided to try it upon multiple recommendations. I did, but the Java quirks were somewhat annoying. I still use Emplode - but I like the JEmplode features outlined above (Hijack auto update, time setting, configurable file naming on download from player)

I really like the idea, I'm sorry I forget who mentioned it though, about maintaining sync between your computer and the player. if you make changes on the computer when you connect the player it auto syncs. But - if your empeg is "multi homed" like mine (I often load music both at work and home) I'm not sure how well that would work.

I really like the idea of doing a full backup image. Not that the drives would crash, but it would be a huge fuss to re-compile my collection, it exists in several locations right now. But, for instance, if I wanted to replace the 2 10 gig drives in my player for a 40 or a 60 or something. I have space to spare on my 120gb drive.

Just for the record (since I'm probably not allowed to participate in this discussion ), on-empeg soups are stored as tags of the soup playlist on the empeg. jEmplode-only soups are stored in the rcfile as you mentioned, though. This is as of 42 at least. Mike

jEmplode winning on stability is one i haven't heard before

I'll take a stab at this one -- I think in the past couple months there has been some gravitation towards jEmplode primarily because you guys have been busy on other things and I've had freetime to continue development. I can tell you the top three requests I have had for jEmplode have been 1) soup-on-empeg support, 2) download w/ tag rewriting, and 3) keeping pc and empeg in sync. #1 and #2 we've pretty much got, though i think #1 is at the wrong level (it would be nice if the Empeg just did this for us), but it's passable. #2 is thanks mostly to Daniel and his work on his ID3 parser/writer. #3 is still not there because it's just kind of a hard problem. I think ideally that Windows folks _should_ prefer Emplode -- if we were feature matched, Emplode would always win because it has the native edge. I always think it's cool when Windows folks choose it, but I think jEmplode's place is on non-win32 platforms... I'll obviously try to keep the arms race going, though Another popular (and easy to add) feature that I think tony mentioned was templated download filenames (i.e. {title}-{tracknr:2}-{artist}.mp3). Mike

If you want to blow JEmplode away and be a hero think replication
Advantages:

..and you haven't even scratched the surface

Rob

Device soup definitely belongs on the player, not in emplode as a playlist kludge. It's in our codebase and is used by several products we have developed or are developing. I don't know why it hasn't migrated to the car player yet but I'm sure it will do so.

Rob

1) One-button (or x buttons ) full backup .
Definitely

That would be nice ... I'd love to get rid of the code from jEmplode ... The only difference right now would be that currently jEmplode lets you define a soup using a search string - which would be a cool feature to add to the product set sometime too.

Second on the soup based on a search, i use it lots

Call me hungry, but what is soup?

It's what your mom tells you to have when you're sick.

Now eat up...it's good for you.

Device soup definitely belongs on the player, not in emplode as a playlist kludge. It's in our codebase and is used by several products we have developed or are developing. I don't know why it hasn't migrated to the car player yet but I'm sure it will do so.

It's not a one-line fix to migrate it to the car-player, Rob, because Central Soup is built on a database backend that (as it has the luxury of an always-spun-up disk and lots of RAM and swap) is much stronger medicine than the car-player one. Future developments in the field of disk-spun-down databases will, as ever, probably see useful fallout for the car-player too. And there's a fine line between a "playlist kludge" and a database whose indexes are rebuilt on the PC...

Peter

..and I know just the man to cross that line!

Rob

Does the empeg explicitly spin down the disks? or is it just that mounting them read-only does so fairly well? I guess I'm asking if there's a difference between a disk-spun-down db and a regular db that's running on a readonly disk...

--pj