jemplode vs. emplode

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

the "soup" is the lump of all your music when it's not in playlists ... it also refers to dynamically created playlists as views onto that lump of music (like "Artists" or "Albums"). So a "search soup" is a dynamic playlist based on a search string (say "artist = 'james taylor' and year > 1980") and every time you add a tune to your Empeg it would automatically appear in that playlist if it matched the search string. ms

Does the empeg explicitly spin down the disks?

Yes. Disks, even laptop ones, have much much better vibration tolerance when spun down. That's important in a vehicle. Also, much less heat is produced when spun down; in some installs, that's important too.

We could just have set the IDE auto-spindown timer, but seeing as we know exactly what the disk access pattern is (in the steady state, it's "cache frantically for two seconds, then do nothing for five minutes, then repeat") we can control the spin explicitly so it's only up for those two seconds, and is spun down the moment it's not needed rather than waiting for a timeout.

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...

The player software needs to be able to get at the data instantly. It can take up to five seconds to wake up a spun-down disk. Imagine how much it would annoy you if going into the Playlists menu or the search screen waited for five seconds before it could show you anything!

(Yes, the disk always spins up when you go into the Playlists menu or the search screen. But that's because it's hopefully going to take you at least five seconds to choose what you want to listen to, so it can start getting music off the disk instantly once you've chosen, rather than waiting five seconds then. The menu appears and is usable long before the spin-up completes. It's attention to details like that which is why you bought an Empeg in the first place.)

The tension is between on the one hand needing to keep all that data in a limited amount of RAM, and on the other being able to access it flexibly and efficiently. The database on the Rio Central is indexed up the wazoo and can (and does) soup to its heart's content, but the data ends up about 30Mb in size on a fullish player, and the thing ships with a 128Mb swap partition which at times (e.g. database rebuild) it's pretty glad of.

But as Rob implies, I have a Cunning Plan(TM), which would be nice to get onto the car-player sooner or later. But that would be waaaay in post-2.0-land.

Peter

In reply to:

---

Yes, the disk always spins up when you go into the Playlists menu or the search screen. But that's because it's hopefully going to take you at least five seconds to choose what you want to listen to, so it can start getting music off the disk instantly once you've chosen, rather than waiting five seconds then. The menu appears and is usable long before the spin-up completes.

It's attention to details like that which is why you bought an Empeg in the first place

---

To be honest, its attention to detail like these that I was hoping I would be getting in the product when I bought two of them...

...I wasn't disappointed.

Its details like that why I bought another two during the firesale.

Its also a lack of attention to those details, why perhaps some of those other (but admittedly, sometimes, cheaper) products don't sell so well.

Thanks again for being so forward thinking - I wish more products were like my Empeg.

It is however a pity the Empeg and RioCars don't have a ton more memory in them that we could use to cache this sort of thing internally in RAM.

Call me hungry, but what is soup?

I know it was already explained in this thread, but I need to get my requisite FAQ Link in here.

Besides, mine has pictures.

"Yes, the disk always spins up when you go into the Playlists menu or the search screen."

So I guess leaving the menu or search screen open for a long time is not a good thing? I think I've done this before.

Ah, but in my defense, I searched the FAQ for "soup". It doesn't come up in search.

"Yes, the disk always spins up when you go into the Playlists menu or the search screen."

So I guess leaving the menu or search screen open for a long time is not a good thing?

It times out and spins down eventually. Attention to details...

Peter

RAM at the time was costing us a lot; we did look at using 64Mbit chips on the Mk1 and original Mk2, but there seemed to be a 300% disconnect from the price of RAM to the consumer and what we could buy reels of chips for.

Someone, somewhere, was making a pile. I seem to remember that the 12MB on the Mk2 was costing us something like $30, which was daylight robbery, but we needed to be buying in 100,000's to get decent pricing.

We were planning a mk2b as an interim (after 1000 mk2a's) which was going to move to the SA1110; we would have lost some speed (206Mhz vs 221Mhz) but would have moved to 32MB of SDRAM which is a lot cheaper than EDO due to the PC uses. It never happened, as Rio were desparate to make thousands of the original (expensive!) design instead of letting me & Christoph do some cost reduction work on the box.

Hugo

very nice.

I use Emplode almost exclusively as it is much faster and more stable than Jemplode on the machine I use and I don't understand why a soup view is desirable - I can always find the stuff I want within seconds so that's all I need.

The only thing I do use Jemplode for is changing my boot animations. I would probably use it for hijack updates except it gets upset when I try it. Seems to want to be able to connect to the internet and not just use a supplied zImage file and I don't ever want to connect that machine to the outside world.

The only extra I would love to see in Emplode is the ability to continue editing playlists etc, or queue up music uploads while a sync is happening ready for the next sync.

I prefer Emplode to JEmplode simply because it works better for me. JEmplode frequently cannot find the files to upload to the player (returns null_pointer error message). Emplode works every time.

My only concern with Emplode is the fact it does not generate a report on duplicate file "problems".

Ah, but in my defense, I searched the FAQ for "soup". It doesn't come up in search.

Very odd! It should have come up.

Here's what I get when I do it:

You should try out the latest jEmplode prerelease and see if it is any better ... I cleaned up a lot of these little issues.

I'm not using Jemplode and don't know if it has this feature I request, but this would be a great kickass feature!

- The ability to save (and then load) settings

As I posted yesterday in Bug Reports forum, my player lose all the settings and I have to re-set all... not a big work since the EQ was still intact, but it would be a useful feature.
It would be nice if we can save all user settings like time format, balance, fader, dimmer, beep and most important the EQ settings.

Linux.

Building Linux into emplode? God, wouldn't it be bloated?

And then you have the fun of trying to get patches you need into it, and play political games...

Oh, I just happened to think of one. Every time I add new songs to a playlist, I have to then hit the little "AZ" icon to sort the files by artist. I'd like a "by default, sort like this" feature. Maybe even tiered:

First sort by artist A-Z
Then sort by title A-Z

-Christian

FITNR, kinda. I added an option to the Tools menu that sorts playlists by title, and tracks by track number. It starts from the currently selected playlist and recurses. It'll usually do what you want.

If I get time, I might add more tweakability.

This concerns me.

I'm just getting caught back up with some recent threads, but I have to say that this is an example of why I try to do so: software guy for EOL product asks "What else can I do?"

Cambridge, I salute you!! Mschrag, I salute you!!

Roger, I use both packages. Hmmm, what could you do? Well, cross-compile on Linux would be good as my Windows desktop is starting to take a secondary role.

Oh, and I don't know that it is strictly related to Emplode, but when Ogg support appears, I will have to call up and (assuming I am still employed!) order some Satay, Phad Thai, Tom Hah Gai....

Damn, now we're either going to have to give you alpha team membership or pay for our own Thai a while longer

Rob

WoooooooooooooooooooooHoooooooooooooooooooooo......!!!!!!!!!!

1. Ogg/Flac support in Emplode ... (Pick up the tags, and drop the files in the DB). Even if the commercial player doesn't support it yet, we've got a 3rd party player that's coming along that does.

2. "Smart synching" between Emplode and a folder heirarchy. You mentioned something similar about a year ago on some thoughts you had for it.

3. Scan for duplicates ... Some means of finding songs that are at least close in title. I find for a big music archive, I get some unnecessary duplication. This "closeness" would mean taking into account minor spelling differences and an additional word in the title (like 'The') and such...

Greg

How about being able to delete more than one playlist at a time. I recently had to delete a few hundred playlists and it wasn't very fun.

How about being able to delete more than one playlist at a time

I have no problem doing that.

Well I'll be durn...

FITPR ?