Is it jEmpeg time again?

OK .. I know I've been hiding for a while, buying (ok, well the bank is buying, I should say ) and moving into my new house. However, now that that's over (if "over" is defined as "30 years of commitment"), I'm starting to feel the jEmpeg itch again, and was curious to see what people would most like to see from it at this point. Are there any bugs that are driving you crazy? Any features that you'd really like to have? Voice your opinions now and whichever ones piques my interest the most wins

Mike

Updating of the ID3v2 tags based on the Database info., preferable in the download step!

i'd like to see findempeg functionality for it. everytime you scan the network at startup, it will put the name and ip address of the empeg unit(s) into a specified hosts file.

Wendy!

Wishes:

1) (As already mentioned) Write freshened tags to files you've downloaded.

2) Update the main "root" Jemplode installer so that newbies don't have to get the latest JAR file. If I recall correctly, the current main Jemplode installer doesn't have the version with auto-updating built-in. Once you've upgraded the main installer to a version that auto-updates (and has auto-update turned on by default), then this becomes less critical.

3) Fix whatever remaining issues there are with parsing tags at import-time. People continue to report trouble with certain files with goofy tags.

4) Fix that bug I'm having where, on only one of my operating systems (2000), the left-hand pane never repaints and just says "loading..." instead of displaying my player contents (we were discussing this in e-mail before the black hole of house-buying swallowed you up).

5) Figure out how to make the mouse wheel work in all scrolling lists.

Mouse wheel - YES!

Yeah, I find that updating ID3 tags is the biggest pain in getting my music organized for use with the Rio/Empeg car player.

It would be very cool if jEmpeg worked in conjunction with a freeware MP3 encoder like LAME, and could automatically rip a music CD into MP3, get tag info from www.freedb.org, and automatically queue the results for synchronizing with the Empeg/Rio Car player - all in one step.

im with brad on the mouse wheel

And it would also be very cool if my toaster also opened cans, chopped up food, cooked it, and washed my dishes afterwards... But I can't imagine what that toaster would look like!

I say let jEmpeg concentrate on syncing MP3's with your Empeg, and leave the CD ripping/encoding tasks to the programs like EAC and LAME that do those well. EAC has been under development for years, and it's widely considered the best... Why try to replicate what they've done? I think Mike's time is better spent on improving jEmplode's interface, fine-tuning ID3/tagging issues, etc rather than duplicating what other programs already do very well.

Yeah, I totally agree. I'd much rather see jEmpeg concentrate on the synch. process than try to be a Do-It-All CD->empeg tool.

Besides which - I don't believe that LAME is available in a java implementation.

Besides which - I don't believe that LAME is available in a java implementation

Well it wouldn't necessarily need to be a Java implementation, JNI could make calls to the LAME libs... But it's still a bad idea.

You know you're the first person I think that's actually asked for this. Does nobody use Wendy filters? I personally don't but only because I'm too stupid to figure them out.... (this is not saying that I won't add them, just that I haven't bothered to understand them)

1) I need to talk to Daniel about this one since that library is his

2) I think the latest is, but I may not have done it right. The new InstallAnywhere is out too, and I'm itching to try it out so that gives me a good reason.

3) Daniel also ... Anyone who is having tag parsing problems, let me know and preferably send me a link to the MP3 that is failing.

4) This one sucks.. I have no idea what's going on. I'll track it down. You're going to have to be a gineau (sp?) pig since I can't reproduce it.

5) JDK 1.4 has this built in, but since only a few OS's have that for now, I'd have to use native code to do it, which kind of sucks. I'll take a look at what the options are. Since the native code would probably only be on Windows, I may try to make this a 1.4-only feature... You'd have to update your JDK, but at least it would be available on Solaris, Windows and Linux (and OS X in a couple months when Jaguar comes out)

Mike

I guess this thread was settled If you have any recommendations for ways to make whatever problems you may be having easier as a more general feature of jEmplode, let me know.

Well, it's the one thing that Emplode does that jEmpeg doesn't, so for jEmpeg to be a true replacement for Emplode, I think it needs to be implemented.

I don't know how many people use Wendy filters - they are a bit of a pain to set up in Emplode, and this may be a barrier to their mass-acceptance. Every track must be individually selected, right-clicked to gain property access and then have it's flags set which isn't very cool. I'd really like to be able to multiple-select tracks and mass-set a Wendy flag on them all at once. (That's way it'd only take me 5 minutes to flag all of the tracks with lyrics that my 19 month old shouldn't be hearing!). It'd also be useful to be able to select a playlist and have jEmpeg recurse through it applying flags - in conjunction with the soup views, it would be very easy to set up "wife-hates" flags on the appropiate genres.

IIRC, there's also some player quirks with Wendy filters - with the current applied filter being lost under certain circumstances or something. I can't remember the details as I'd only just joined the commnuity when the discussions on this were taking place..(Tony!!?).. But I don't feel that this should stop jEmpeg from being able to create them, and might help add impetus for these quirks to eventually be ironed out.

Thanks for the great work

Every track must be individually selected, right-clicked to gain property access and then have it's flags set which isn't very cool. I'd really like to be able to multiple-select tracks and mass-set a Wendy flag on them all at once.

As far as I know, you can group-select tracks in Emplode and apply properties including Wendy flags.

It's theoretically possible that this is only a beta12 feature and that's why I can do it and you can't. If you really and truly can't do this in beta11, well then it's a FITNR.

Do you mean you'd like a commandline tool that just does the network discovery?

I think he means by selecting a playlist, not just multiple tracks, and tagging the entire playlist with a particular wendy flag. I know that is something I would love to see. I am currently switching back and forth between emplode, and Jempeg to get my playlists, and wendy filters how I want them.

In reply to:

---

Do you mean you'd like a commandline tool that just does the network discovery?

---

yeah. something automatic. might as put it in one step, instead of running 2 programs.

Does anybody use Wendy filters?

uh, yeah !?
Wendy's a hot little mama.
I had MY girlfriend go through all my music in emplode and
select all the music she likes by marking it with a "Her Music" Wendy.
Now when she's around, I just hit down,down,down and apply her filter.
Then when she goes to fiddle with the d4mn thing I say
"You told Wendy to play this, so leave it alone"

In reply to:

---

Does nobody use Wendy filters?

---

I don't - but I might if JEmplode supported them. OTOH, I haven't really looked at what they might do for me (since I don't have a tool to apply them, and I don't know the syntax to do it in emptool).

I'd like a way to edit all a tune or playlist's properties in JEmplode, not just the ones that appear in the database. Emptool allows setting of arbitrary properties.

For instance, it would help me organise my "singles" playlists if I could add a "release date" property to them all, and then use that field to sort them. Emptool lets me add the property, but it doesn't sort playlists. I could use the "comments" property for this but (a) I tend to use it to annotate marked tracks with the reason for marking, and (b) that's using space in the DB for information that's not useful player-side.

It would also enable the removal of obsolete properties from previous versions of emptool.

I'll take a look at this one ... I think the best I could do is String sort it (i.e. it wouldn't be able to know the data type of that field -- though maybe I can provide an additional interface to setting that too...)

String sort would be fine (for dates, I would use ISO 8601 format YYYY-MM-DD, which sorts lexicographically).

If people need numeric (or other) sorts for their custom fields, it might be possible to extend the View->Columns dialog to specify the sort rule for each column.

After editing a FID (tag) and hitting OK the files portion of the screen defaults back to the top of the list, not the file you were working with. This can be very irritating if you're fixing a lot of tags on the empeg (I know, I know mp3 tagstudio).

That's my $0.02.

-Zeke

I'm seemingly unique in not paying much attention during the Mp3 ripping and encoding process - I just keep stuffing CD's in to my PC at work and let AudioGrabber do it's stuff.

Which means that I tidy up the tags for the files once they're downloaded to the empeg, using emplode or jemplode.

What I'd really like is a feature that allows a bunch of tracks to be selected, then choose a menu option that swaps the artist & title around for those tracks. This is a real pain to do manually, and happens quite a lot with the Freedb tracklistings.

I'd also like a quick filter for duplicate tracks (same artist & title, but different sources) so that I can review them and decide which ones to keep. This is a real pain to do manually, with 5000 tracks!!! I've posted a similar question in the general section here but this seems a more appropriate place to pose the question.

Cheers.

In reply to:

---

I'd also like a quick filter for duplicate tracks (same artist & title, but different sources) so that I can review them and decide which ones to keep. This is a real pain to do manually, with 5000 tracks!!! I've posted a similar question in the general section here but this seems a more appropriate place to pose the question.

---

there is a shareware product called Mp3Utility that filter dupes based on a percentage of the filename being the same... but you have to do this on your original collection.

btw, anyone who has an open-source alternative to the program above, be my guest and tell me =)

I know that this is a big project, but it would be nice if Jemplode would sync a directory of mp3s on my pc with the empeg. Similiar to rsync but for windows and mac users.

Sean

Make the Command key work for copy and paste and stuff instead of just the Control key on Mac OS X.

Oh, and also make the full installer on the other systems install a 1.4 VM. Heck, why don't you make it install a 1.4 vm on my OS X machine as well? (hee hee)

One thing I'm just realizing I'd like is for it to ask me to do a sync if I click exit and have not yet.
Emplode does when you click exit, and it's nice...

Hi!

I have some strange things happening when i use jEmpeg 36(both at work and home, Both using linux).

I think the scenario is somthing like this.
* Arranging music thats added but not synced makes the playlists disappear and/or nesting with other (wrong)playlists. Totaly strange and hard to explain.

* And I cant sync more than like one album, if I try more it just looses connection, and I have to restart the player.

* At one time "it" managed to make a "loop" with the playlist like:
Artist1Playlist->Artist1AlbumPlaylist->Artist1Playlist->Artist1AlbumPlaylist-> and so on... Rebuild the database didnt work it out, jEmplode 36 just hanged when getting playlist(I think). Tried jEmplode 2.0B11(I named it that way... Dont know if it was the real version numer) It saw the error, reported it, tried to rebuild the database, rebooted and tried to get the playlists over and over again(never stopped).

The only thing to fix this mess was vmware and Emplode....

It worked quite allright before 36...

All was with ethernet, Beta11 software.
Sorry for the bad explanations, but I didnt write the errors down was too upset

/Fredrik

Check your options and see if fast connections are turned on ... If so, try turning them off and syncing again (this might fix the problem with the connections dropping). I'll need to look into the other ones ....

Fast connections was turned on, I'll do another try soon and let you know the results.

(Forgot to tell you THANKS for a great job on jemplode! )

/Fredrik
Empeg - Blue - 50gb

In reply to:

---

Are there any bugs that are driving you crazy?

---

Dunno if it's a bug or not, but it's driving *ME* crazy...
After sync' with Emplode, next time I use JEmplode, it'll complain that "1 errors were fixed, syncronize to repair." (Or something like that.) In JEmplode, the main "Playlist" entry (in the tree) will be marked like it was 'changed'. But for the life of me, it looks all the same.
Then, after sync'ing again, and the next time I run Emplode, it will flag the main 'Playlist' tree as being updated (It don't report that there was an error, just 'fixes' it), but it, again, looks the same.
So, whatever setting I have somewhere in my playlists, Emplode wants the database one way, while JEmplode wants it the other way, and the two start arguing about it. Of course, I don't know if there's a way to see what JEmplode is having a problem with-- is there? It gets annoying after just running either one, and getting an errror message when I try to exit, warning that I'll lose my 'changes'.

Mike..

Ahh, with the fast connections turned off the sync goes much better!


Thanks!

/Fredrik

Usually, that problem is related to a non-mp3 file that was uploaded... jEmplode keeps trying to figure out the bitrate of it. It is a bug... I've been trying to get my implementation to match up to Emplode, but it's still not exactly right...

Mike

In reply to:

---

Usually, that problem is related to a non-mp3 file that was uploaded... jEmplode keeps trying to figure out the bitrate of it. It is a bug... I've been trying to get my implementation to match up to Emplode, but it's still not exactly right...

---

Uh-oh. Anyway to tell WHICH file? I have nothing BUT mp3's.. (I DO have an MP2 file, but it won't syncronize in Emplode..) I'm curious as to which one's messed up..

Me.

One of the things I'm spending time on in jEmplode 37 is handling errors and fixing tags. There's a much better interface to it now so it will tell you exactly what it found and either attempt to fix it or give you the opportunity to delete it. If you choose not to delete it, it will colorize the offending nodes so you can go in and do something to it later.

Mike

jEmplode will upload everything. Emplode will not. I have some cover art (jpegs and gifs) as well as some random log and text files (lyrics) in my MP3 file tree. jemplode dumps them onto the player, emplode realizes they shouldn't be there and doesn't upload them.

When I try to download them later, they have their regular extension and then .mp3 added. i.e. filename.txt.mp3. If it's going to upload files other than mp3's, make sure it realizes that and then dumps them back off the empeg as such. It's a great way to back up or transport large files (digital pics backup, email, address book, etc.)

jEmplode 37 is much smarter about this. One of the problems is that jEmplode doesn't care about non-MP3 files (for transport purposes like you said). However, it doesn't currently set a codec on the files (since there isn't a codec for a .txt file). The problem with that is that currently not having a codec is one of the triggers for Emplode to "upgrade" the tune from the 1.0 series. So it appears that Emplode goes through and sets the codec to be "mp3". I'm going to try setting to codec to something bogus to see if Emplode will ignore it...

Maybe the Empeg guys and I can agree on a standard "magic" codec that can be used for taxiing files.

As part of all this, 37 fixes that downloading problem too (i.e. wrong extension attached).

Mike

It's a great way to back up or transport large files (digital pics backup, email, address book, etc.)

Uhhhh ??? - So is FTP.
And it's a heck of a lot faster than ( j ) emplode.

FTP does 'bout 8 Megabits/second on my setup through a 5 port switch.
That's 1 Megabyte / second, nearly double the speed of a sync,
plus no need to rebuild the DB, which takes about an eon with all my playlists.

So is FTP

Yeah, but jEmplode would be infinitely faster if you didn't have access to an Ethernet network, and still much faster if you had to manually configure IP networking, assuming that USB is available.

OK .. I settled down and rewrote a bunch of the playlist tree manipulation and event code, and I was able to get rid of all these things you talked about here... One nasty problem in <37 was that it never checked for loops in the UI (though after sync, it would probably have caught them -- but that would result in db errors). 37 will properly look for loops through the UI and not let you create a scenario like you were talking about.

37 will have this.

Do you happen to know what the Java KeyStroke settings are for Command-X on the Mac? I can write a little test program if you don't know offhand, but I thought I'd ask first ...

I've actually not used rsync .. Can you describe roughly how it works? Is it basically mirroring? Does it sync bidirectionally (i.e. if you update your Empeg at work and come home and rsync, will it put the new work mp3's on your home machine as well as new home mp3's onto your Empeg?)

ms

OK, 37 will have this. You'll have to run it yourself (there won't be a top-level excutable for it), but if you were to do:

java -jar jemplode20.jar org.jempeg.empeg.protocol.NetworkEmpegDiscoverer

it would print out something similar to hosts format to stdout (I say 'similar" to hosts output in that the name of an empeg can have spaces, etc. in it, but you can filter that with perl or something if you needed). So it would print:

192.168.1.100 Mike's Empeg
192.168.1.101 Kirsten's Empeg

Is that enough to just print to console? Can you chain commands together to echo it out to a particular file?

Mike

Wow .. yeah .. that was annoying .. this is fixed in 37.

Do you happen to know what the Java KeyStroke settings are for Command-X on the Mac? I can write a little test program if you don't know offhand, but I thought I'd ask first ...


Nope, don't know. That's just like me, though. Ask for something and then offer no help in implementing it.


However, maybe you should check this out: http://developer.apple.com/technotes/tn/tn2042.html


It speaks of the java.awt.Toolkit.getMenuShortcutKeyMask() method, which is supposed to take care of that for you and remove platform specific coding for the menu shortcuts.

Wow .. cool I never knew this method existed. Always wondered what the right way to do this was...

Thanks
Mike

"I've actually not used rsync .. Can you describe roughly how it works?"

Me neither, I just keeping reading about how great it is on these boards.

"Can you describe roughly how it works? Is it basically mirroring? Does it sync bidirectionally (i.e. if you update your Empeg at work and come home and rsync, will it put the new work mp3's on your home machine as well as new home mp3's onto your Empeg?)"

Yes, you just described how it works. There are some problems with fid numbering and having to resync in emplode before the new music shows up I think. The database also has to be rebuilt so getting around using emplode/jemplode was difficult.

Sean

Mike, I was having some shuffling problems on the player for a given playlist. I brought up jempg, and properties on the playlist had the "always randomize" checkbox CLEARED, which is what I wanted. But the playlist was still shuffling.

So I brought up emplode, and it had the checkbox CHECKED. I hadn't done any sync's during this period.

Have you seen this before? I believe I am using v36
rjf&

Oh, and one other thing. An advanced search for "refs=0" showed nothing when done from jempeg, but had results present under emplode.

Sorry if this is already known, or is lame :-)

rjf&

I believe that there's a problem with the advanced seraches under jEmplode v36. If you have open the console where it started from (a problem under some OSes, I realize), I believe you'll see it throw a non-fata exception having to do with some string library. Mike's told me it'll be fixed in v37. Maybe it already is in his pre-v37 pseudo-release, which I haven't bothered to check yet. Search the forum for tfabris-jemplode, IIRC. Edit: Hyah 'tis.

Were these bugs in the latest version of the JAR, the one that's mentioned elsewhere in this thread, version 37 I believe?

If these bugs were with version 36, then don't worry about them unless you can verify them in version 37. He did some bug fixes since 36, and it would not surprise me if the flag-handling was one of the bugs fixed.

I did a refs=0 search in 37 and it works, so maybe try it then....

I'll take a look at this ... I never use these flags, so I never see them myself. I totally believe there could be a problem there...

Mike

The only thing I can say for _sure_ is that I was able to turn on, sync, it was on; turn off, sync, and it was off for Randomize Contents and it seemed to work. This is not to say that there wasn't some weird problem compounded by something else when you ran it. These will be easier to debug in 37 because there's an advanced tag editor that will show you exactly what's up with all the tags...