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