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.

Peter says FITNR.

Actually, that was a different, player-side bug -- although caused by the same underlying misunderstanding (by a different person!). The emptool/emplode bug, which affected all very-low-bitrate VBR files, is now FITNR too.

Peter

In reply to:

---

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.

---

Have you tried this in 42 by any chance? I thought this was fixed (at least it is for me using JDK 1.4).

Have you tried this in 42 by any chance?

I'm holding off until some of the other bugs people have been talking about are fixed. For instance, it's critical to me that {pos:2} works in all cases, but others have said it doesn't work for them.

Am I missing anything?

I would love it if Jemplode could read the contents of the 3 bookmarks
and make them appear like playlists attached to the playlist tree.
Kind of like the soup lists are.

Then you could make a playlist from the front panel and save it is a bookmark,
then next time you open jemplode, you would see the playlist you created.

I don't know how the Bookmarks are stored,
but I can only imagine that they are readable.

Is this possible?

Haven't even used bookmarks before I would guess they're stored in config.ini, though.

No, they're not stored in config.ini, at least I don't see them there.

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=4&faqent=129#129

its probably stored in the mysterious /dev/hda3 partition.

perhaps for this purpose, jEmplrode might be able to uncover the mysteriousness of said partition,
What's so mysterious about it anyways?

its the scratch partition that the player software writes non-flash info (all statistics including plays, marked, etc.) using sector-level access.

OK, so perhaps, Jemplode could decode all of this information for us???
Perhaps we could then be able to actually edit the number of plays for a given track,
so we can also get rid of those unsighly tracks marked "plays: 65,536" ?

you should already be able to from the advanced tab on the properties dialog ... i think

you should already be able to from the advanced tab on the properties dialog ... i think

mmmm. NNot sure on that one,
I remember being dissapointed that I could not change this,
but I have not checked the most recent version,
will get that tomorrow and test......
thanks Mike.

I have a request... In previous versions there used to be selections under Playlists tab on the left for Playlists, Artists, Albums, Genres, Years, Artists/Albums, Searches, All.. In the new versions these views are not possible..

Maybe I am missing something but Can we get these views back as an option?

They don't appear by default anymore (though I may create some default ones in 44 if you don't have any setup).

If you go to Tools=>Add Soup Playlist... then give the playlist a name ("Artists") and click "Add Tag Layer" and select "By Artist" that will create a soup view for Artists. Likewise you can go and add several layers to make more complex views of the player.

Mike

That is what I needed..... Thanks...

Talking of soups, would it be possible to exclude them from the exported XML?

The reason I ask is that when I was testing my changes to the XML exporter, the diff suggested that I'd changed a lot on my player because the soup views get different FIDs each time.

Or perhaps we could have a different format for FIDs for (off-player) soup playlists? Don't know whether you use integers internally for this.

Yeah ... in fact, when you're looping through FIDs, I think you can call .isSoup() on the IFIDNode to know whether or not to skip it ... I don't remember if that is done in the Abstract one or in each of the concrete classes.

For those who care about this bug, once the NR comes out where it is FI, I'll port the bugfix and it will be FITNR for me too

Please could we have JEmplode use "Sort by Position" for new installs and whenever the "Set Playlist Order" function is used?

just to add to this request: it would be nice to have independent sorting for each soup. (i.e. one soup sorted by tracknumber, and another sorted by title).

thanks
-ted

Yeah, I tried this, and the Advanced tab is the only place that this information is editable.
I changed the plpays value from 65535 to 0 and hit OK.
The tune turned red, annotating that it had been changed, and I did a sync.
The tune was still marked plays:65535.
PLEEEEAAAAZE fix this. If you need me to do any sort of testing, let me know.

- thanx

Just out of curiosity, did you hti "enter" after changing the value of the play_count in advacned? There appears to be a bug in the advanced view that if you just change the value and hit OK without hitting enter first, it won't save the value. When i did this, I was able to update play_count.

Mike

I cannot confirm nor deny that, senator.
However I will test it this evening.
- thanks

Hmmm whats the chance of getting some VBR header fixxing code added
would be really nice to be able to select a file with a dodgey header and jsut hit - fix vbr- and have it do all the work on the player

what types of VBR problems?

Like, for example, when the VBR TOC is complete tosh, maybe?

The problem with this is that the file would effectively have to be completely read back from the player. This wouldn't be such a problem with Hijack installed -- you could just grab it with FTP, I guess. It would be quite slow over the normal protocol.

On my list of things to do in my copious free time is a VBR fixer that you run on the player at a shell prompt, that would fix up all the duration/bitrate tags in the *1 files as well.

In reply to:

---

On my list of things to do in my copious free time is a VBR fixer that you run on the player at a shell prompt, that would fix up all the duration/bitrate tags in the *1 files as well.

---

I was about to ask for one of those (at least the latter half), so if you get some CFT....

OTOH, if I get some first, I might have a go.

In reply to:

---

9) reliable deduping

---

Hey Mike, how is this coming? I have been holding off on re-uploading all my stuff because I assume you are going to change the dedup method and the checksums would be off so I would have to re-upload everything again. Just curious when this might get more or less stable.

Thanks,
-Mike

honestly, the next major release will be several weeks out (I have another home project that I will likely be working on for a little while)... what I can do, though, is plan to at least provide an easier upgrade path that will recompute the hash value for the songs you already have uploaded (granted this will take just as long as reuploading, but without the hassle).

oooh bacon...I smell bacon. Can 43 make bacon???

I still have this problem in jEmplode 44, all variable bit rate files once uploaded via jEmplode are reported as having a "vs0" bitrate, whereas Emplode gives the correct bitrate value. I assume that the bug was never fixed in jEmplode. Are there plans for a new jEmplode version with this bug fix?

Ross

MP3 parsing was overhauled for the Karma as a port of the Rio MP3 parser ... I haven't specifically looked at this, but I would _guess_ that it works now. I'm very slowly getting jEmplode rebuilt from the tiny pieces that it exploded into for the Karma. Once I do, I'll check this out.

OK... Maybe what I'm asking for is avialable or doable or whatever. But here we go...

I got a Rio Receiver a bit ago and finally got all working with Jreceiver (and Trio). Well, the Jreceiver server does some things I REALLY like and would love to have the interface to the Empeg do the same.... I have a LARGE music collection (31,000 songs or so) all on an external hard drive. Well, as I'm always getting new music, it does a search every morning at 5AM for new music and adds it to the database. Having a database of available songs to send to the empeg would be nice... but the new RIO Music Manager (used by the Karma, Riot, etc.) does something I like also... On sync, it will replace a percentage of what is on the player with new music and you can customize how it fills the player up.

SO, what I'd like to see if doable is to have a database available to choose music to send to the Empeg and then when you sync the player, it will automatically download possibly the newest additions to the databse as well items as it does now...

Is this possible? If so... I'd LOVE that option

Jemmi

I don't see it listed already, but I'd LOVE to have the year and genre fields of the tags written when downloading mp3s off the empeg with jEmplode...

I've been waiting a long time for that to get implemented... Please add it?

- Jon