Here's what I have so far:
1) support for */? matching in search strings
2) support for wordbreak character in search string
3) ctrl-shift-c that appends to clipboard rather than ctrl-c that replaces the clipboard
4) (maybe) make the clipboard appear as a playlist (so you can modify what you're going to paste)
5) allow "marked" to be bulk set/unset
6) fix the soup sorting issue
7) drag-n-drop reordering
8) drag-n-drop copy-n-paste
9) reliable deduping
10) fix bugs with multiple-select play/insert/append buttons
11) per-playlist sort options
12) fix bug with sorting mixing order of equal values
13) empeg<=>pc syncing aka Empeg Backup
14) ogg import / tag parsing
15) flac import / tag parsing

Am I missing anything?

On the "Emplode vs jEmplode" post, a couple people mentioned that the Java UI had some quirks ... I'm curious what people most dislike. It may be possible for me to fix some of the quirks that people most dislike ...

Mike

If you click on a single playlist in a group of lists in the left pane and "set playlist order" it sets the order of the children in that list to the order they are in now.

if you select mutiple playlists in the left pane and "set playlist order' it sets the order of the parent.

if i could select multiple playlists in the left pane, "set playlist order' and set the order of the children of each list selected, i wouldn't care about the soup sorting issue, but i can't speak for the other person(s) who suggested it.

Small fix that would help me out. I would like the ability to put ( ) around the soup playlists, so that way they are up near the front so I don't have to hunt through all the playlists I've got to get to a soup. It's what I do to my theme playlists so I can find them easier.

a couple of things.

1) with the on-empeg soups... they don't update if we use emplode to up the new songs. so it seems that you need to upload w/ jemplode for it to. haven't tested yet, but it would be great if they autorefreshed next time you open jemplode.
2) in the advanced searches text box, there needs a way to have escape codes. i cant use the character ( no matter what ... i.e. (artist like "eon ") or (title like "(eon ").
3) is it me or does jemp42 slow down to a crawl when i do a "whole collection drag" and it tries to filter out dupes?
<edit> i just read the changelog. i didnt realize that hashes were implemented. i promptly ran diskbuilder and am in the process of importing. taking a while, so g'nite.

and because of the crc32 check taking as long as it does, i'm going to request a autosync after import if idle for X minutes. had to wait til all was done calculating before i'm able to sync up and sleep.

I have a wish that if fulfilled would be sufficient to convert me from Emplode.

I'd like to be able to create a soup on Artist/Album/Tracks where the track count is >= n

E.g.
(Artists) A-D, E-J, K-L (etc)
(Albums) A-Z
(Tracks) <By Track No.>

I know most of this is possible but I want the no. of tracks parameter to avoid creating 1 or 2 track album entries.

ok. i just got to thinking.... i was looking at my taskmanager when each file's crc32 check was being generated.... and it was only peaking at 20%. can you optimize jemplode to have more than one thread calculating crc32 checks? seems like such a waste of cpu cycles doing it one by one.

Can you please fix the file download features that seem to be broken like "write tag on download" and writing the correct track number when downloading?

- Thanx
- Jon

Hmm.. how about semi-automagic installation of 3rd party apps into /dev/hda2 (and/or /dev/hdc2 for dual drive empegs). It would be useful if the user could just point to an application directory, and JEmplode could figure it out from there - perhaps reading an ftp .install script containing (eg)

site rw
put gpsapp /programs0/gpsapp
site chmod 755 /programs0/gpsapp
put M50gpsapp /etc/preinit.d/M50gpsapp
site chmod 755 /etc/preinit.d/M50gpsapp
site ro

(Hijack ftp SITE commands should rw and ro the /programsX paritions...although it seems that sometimes my empeg crashes immediately after site ro...)

Gotchas:
We should test for both /programs0 and /etc/preinit.d before running the script. Even if an app is so large that it uses one of the music partitions for data storage - the existance of /programs0 and /etc/preinit.d tells us that the empeg has been prepped for 3rd party apps.
It would be cool if eventually JEmplode could do the prep stage if necessary, but this currently involves either serial or telnet access.

well ... technically yes, but there are some issues if you're loading multiple songs that have the same hash value -- it would add it to the database, then the thread would have to find out that it already was in there and then delete it, which is a lot trickier than the current way of verifying if it should go in before it gets loaded (i.e. serialized).

Another problem with this is when the application is already running. You can't just overwrite it's file. What is possible is to upload it under another name and then rename it over the original, this unlinks the original file. However, when remounting the drive as readonly, the unlink cannot be 'finalized'. I'm not entirely sure how the filesystem recovers from this, perhaps the removed copies are only really removed during the next fsck.
As gpsapp conflicts with both serial console and the player when we're on AC, I'm considering simply not starting it when we're not in the car, which ofcourse makes life a bit simpler for upgrading, but it doesn't help other applications.
One thing that applications could do is check whether the inode number of the executable has changed, and re-exec themselves. They might be able to do this before the filesystems are readonly again so the old blocks are nicely released, but we're likely stuck in the hijack ioctl around that time...

You're probably blocked waiting for IO the remaining 80% of the time. Adding more threads could very well increase the number of head seeks and reduce readahead (due to increased memory pressure) which slows you down more than you gain. I guess you're on windows, why not try to defragment your drive first.

On the "Emplode vs jEmplode" post, a couple people mentioned that the Java UI had some quirks ... I'm curious what people most dislike.

Note that most of the interface quirks I noticed have been solved by installing the Sun JRE and having JEmplode use that instead of the Microsoft JRE. Things like the mouse wheel not working properly in the file dialogs were solved when I did that.

Of course, this caused problems with certain web-based java things in IE, but then that was solved by configuring IE to still use the MS JRE, so for the most part I'm a lot happier than I was.

With that said, there's still some things that bug me (FYI, I'm still on Jemplode 41):

- Can't drag and drop songs and playlists. Gotta copy and paste.

- Every time I open something in the right-hand pane, the columns all go back to the same size instead of how I'd stretched them before.

I can't remember what else at the moment.

Am I missing anything?

I think already mentioned in this thread: A working option to write synched V1 and V2 tags to downloaded files.

And here's a new feature idea I'd like to see in Jemplode and Emplode both (I'll try to go find that Emplode-feature thread and add this to that thread): Optional "totals" at the bottom of each column. That way I could see things like the total file size for a set of MP3 files, the total time, the average bit rate, the total number of tracks, etc.

Good point....We need to think of a more robust solution for that - one that doesn't depend on application developers taking it into account.

Perhaps JEmplode should : rw, chmod 000 /etc/preinit.d/ , ro, reboot, rw, chmod 770 /etc/preinit.d/ (whatever...only the root user exists), and then do the install/upgrade. Brute force I know, and if something went wrong during the upgrade, the user would have to use ftp to chmod /etc/preinit.d back again, as telnetd/sshd wouldn't be running. But it should work.

How about installing an N00 script to perform the upgrade and then unlink itself?

Doesn't that still leave us with a chicken and egg situation? The script would be trying to remove itself whilst running - requiring the (flash) drive to be rw, but surely we'd still want ot be nice to flash - ie leaving it ro when rebooting.

A script isn't a program. It's data to /bin/sh. You shouldn't have the same problem with regards to remounting. But I could be wrong.

Hmm...I hadn't considered that. You're correct of course. I've just tested /etc/test.sh :

!#/bin/sh
while true
do
echo "1\n"
done

remounting ro, rw,ro etc worked fine without any hiccups. So another potential strategy: JEmplode puts apps into /programs0/install/ , and N00install moves any /programs0/install/ entries into /programs0. There isn't any need to remove N00install - it should just exit gracefully when it has nothing (left) to do. The only issue with this approach is that it makes it more difficult to utilise /programs1 on dual-drived empegs, but that really isn't a concern at the moment - since the preinit script needs to know the location anyway.(unless we start setting PATHs etc). My goal here is to make 3rd party application installs as painless as possible for the non- unix/linux -savvy, and to perhaps make it quicker and easier for the rest of us...

Speaking of which...

Am I missing anything?

Please.

(You already know what I am going to ask for here... but I'll repeat it for the umpteenth time.)

A "one click" backup utility that runs on a Windows platform that will create an exact mirror of my empeg player onto my PC's hard drive, including music, database, metadata, everything required to restore my player to the exact state it was in when I made the backup. This backup file can be a single large file that cannot be read, played, modified or anything else in my PC if that makes it easier.

Ethernet, USB, even serial -- whatever would make it work.

Pretty Please?

tanstaafl.

I want this also :-)

My mind said :


I WOULD like this ....

and not I WANT

Please add "fix the bug that sets all uploaded tracks' bitrate to vs0, and the one that reads MPEG-2.0 files as twice their actual duration".

Thanks.

Didn't you find that Emptool also did this way back when you first discovered the problem? Does Emplode do this also?

Emptool gets the duration wrong for MPEG-2.0 files in the same way as JEmplode.

It gets the bitrate wrong by a factor of two for MPEG-2.0 files, and thinks they are stereo. JEmplode thinks these are all vs0.

It gets bitrate and mono/stereo correct for MPEG-1.0 files. JEmplode thinks these are all vs0.

Emplode, I've no idea about, and can't investigate, as it's Windows-only.

Emplode, I've no idea about, and can't investigate, as it's Windows-only.

Emplode does the same thing; but Peter says FITNR. (here)

tanstaafl.

Mike,

Thanks so much that you are carrying this forward! Keep pushing

Features I would like are (in order of importance)
- sync with PC. when I had my pervious MP3 player (NEO) it would come up as a virtual drive on my PC. I was able to create a briefcase under windows, and drop all my music in there. so if i were to add or delete stuff on my PC, it would do the same on the MP3 player when doing the update. that is what i miss most with the RIO.

- being able to sort soups under different criteria would also be nice.. since i use soups to generate my albums, it would be nice if they played in track order.

- finally, i dont know if there is a nice way to handle compilations. CDDB always puts in "various artists" in the artist tag, and then puts the artist and title in the title tag. I've been retagging all my music so the real artist is in the artist tag. however, the only way to play the entire album would be to do a soup sorted by albums. so is there a hack that can be done such that all albums that have the same album tag, but different artist tags are put in a "compliations" playlists when sorted by artists? hope that makes sense?

take care
-ted

it would come up as a virtual drive on my PC

Ooh! Write a virtual filesystem driver that uses emplode as its back end. That would be cooool.

Small cosmetic fix: Limit the total/free space display to 2-3 past the decimal point.

I would really wish for a clone tool that will work. I guess it works for some but I'm guessing certain serial numbers (still can't see why use this method) won't let JEmplode see both my players.