49 is up at http://www.inzyme.com/rio/empeg ... Same deal as 48 ... Just the jars right now since I'm sure I'll be building another soon. This adds Mike Comb's fix for Hijack uploading w/ the new FID layout, a bunch of work to decrease runtime memory usage (it should be substantially less now), the player reboots after database rebuilds now, and some other miscellaneous things inherited from RMML.

This is, of course, in addition to the new stuff in 48 (that is mostly experimental) -- like in options you can enable fast database rebuilds if you have hijack installed and a v3 player, so it will rebuild the db on the client. This is very new, and will have issues. Fortunately the worst case is your player just has to rebuild on its own.

There's also an option to enable tag updating on duplicate tracks, so if you change tags on the PC and drop your dupes onto jEmplode, it will update the tags.

The error message for duplicates is more descriptive now, so Loren should never have to wonder what tune the import is a duplicate of again

Oh yeah, you can delete graphics.jar now from your plugins folder ... I merged it back in.

The jemplode.jar binary includes Rio Music Manager Lite binary, which allows you to have FLAC support and a better tested OGG parser. If you don't like binary only, you can build/run from the sources but you won't get a flac parser and the ogg parser isn't nearly as well tested. This jEmplode will also discover and communicate with your Karma if you want to play around with that.

If you want to force a rebuild of your database from the commandline (if you have hijack and a v3 player), you can call that directly with:

java -classpath jemplode.jar org.jempeg.empeg.protocol.RebuildDatabase <yourplayeripaddress>

This will do a full database rebuild from scratch, which is even newer than the fast rebuild on sync (which runs off of your in-memory database, so is less likely to explode). Same deal though .. The worst case is that you just have to let the player rebuild.

Good luck and godspeed ...

ms

Mike, FYI: the Plugins menu is duplicated.

Do you mean you have two animedits and logoedits? Did you delete your plugins/graphics.jar? If not, that's the cause ... I merged logoedit and animedit back into the main jar file (though they still appear under the plugins menu)

If that's not what you mean, can you explain more what you're seeing?

Yup, that's all it was! Now to test out v3 for the first time... crossing fingers!

Yay! Thanks Mike!

when i'm uploading songs, i get this in the serial log:

kftpd: filp_open(/empeg/fids1/_00004/200) failed (-2)
kftpd: filp_open(/empeg/fids0/4201) failed (-2)
kftpd: filp_open(/empeg/fids0/_00004/201) failed (-2)
kftpd: filp_open(/empeg/fids1/4201) failed (-2)
kftpd: filp_open(/empeg/fids1/_00004/201) failed (-2)
kftpd: filp_open(/empeg/fids0/420f) failed (-2)
kftpd: filp_open(/empeg/fids0/_00004/20f) failed (-2)
kftpd: filp_open(/empeg/fids1/420f) failed (-2)
kftpd: filp_open(/empeg/fids1/_00004/20f) failed (-2)
kftpd: filp_open(/empeg/fids0/40e0) failed (-2)
kftpd: filp_open(/empeg/fids0/40e1) failed (-2)
kftpd: filp_open(/empeg/fids0/40ef) failed (-2)
kftpd: filp_open(/empeg/fids0/4250) failed (-2)
kftpd: filp_open(/empeg/fids0/_00004/250) failed (-2)
kftpd: filp_open(/empeg/fids1/4250) failed (-2)
kftpd: filp_open(/empeg/fids1/_00004/250) failed (-2)
...etc.

it seems to work, but just wondering why this is happening. it seems to happen everytime the transfer details is doing "Update <PLAYLIST>". don't think this has been happening before.

Whats happen, if you delete a playlist and do a sync after that. I had this morning after the sync a empty playlist with alpha5. Even the successful command line database rebuild was not bringing my playlist back.

I will try it again tonight, after downgrading to alpha3.

bye

when i'm uploading songs, i get this in the serial log

That is normal (although new to this version) if you have use hijack enabled in the preferences. jEmplode has to look for the files over ftp in several locations and hijack prints that for all the locations where the files aren't. Its a harmless side effect of using ftp for the file uploads. Hopefully you are also noticing somewhat faster uploads?

-Mike

heh, i was uploading more files, and then decided to try out a new boot logo, so i decided to open up animation editor. low and behold, while the sync was running, i wanted to see what would happen if i were to flash the bootlogo. the jemplode windows froze, but the uploads kept on going. have to wait this out to see what happens when the uploading is done.

cool. there should be a SITE command to suppress those things. btw, i thought it was that, but unchecking "Use Fast connection" didn't make it stop, so i assumed it wasn't part of your patch.

That's just plain dirty ...

This is actually slightly different than fast connections. Fast connections is a feature of the Empeg protocol vs Mike's patch which uses Hijack to do uploads.

ms

.. oh I just remembered another new feature is Add To Playlist, which uses RMML's nicer procedure for creating/adding tunes to playlists.

ms

I'm not sure I understand ... You deleted a playlist and it didn't go away, or you deleted a playlist and all your playlists were missing? I just tried it to delete a playlist and sync with alpha5 and it worked. Do you get any error messages?

Hello Mike.

Yeep all the playlists were missing and the next time I connected to my Empeg with JEmplode 49 I got an Error. Can't remember exactly the message. Something with FIDS2*#
But I am right now in the office and have my Empeg at home, waiting for daddy I will try it this evening again und give you a better feedback.

bye

Ah yes ... I'm assuming it was not able to write the the tags file for some reason. Someone else also got this error. Can you run jemplode from the commandline and try again:

java -jar jemplode.jar

and send me the output that appears on your console from that run? Should be an error from the ftp client ...

ok...I will do that later today...

bye

Hijack v349 will be released shortly:

-- supress unnecessary serial port messages for "file not found" from kftpd

cheers

cool!

ok, well, good news is that it finished the upload great, but jemplode was still frozen, and it erased my previous boot logo and went with the stock hijack penguin one.

And apparently 350? (The CVS repository maintenance script picked it up)

Hijack v350 (now out) has just one change:

-- restores "waving Tux" as the stock animation (yay!)

Cheers

MIke...

I did downgrade to alpha3 and was making sure that I can see the playlist. After this playlist, I did upgrade again to alpha5 and was deleting a playlist with JEmplode 50 on my MK-2a with Hijack V350. After deleting I have again a empty playlist on my device.....I did a text file with additional information for you with two screenshots. See the attachment.

Hope this helps...

bye

Weird, so the commandline rebuild executes with any exceptions appearing at the end? Can you run the commandline database rebuild, ftp onto the device and get /empeg/var/tags, /empeg/var/playlists, and /empeg/var/database3 and email them to [email protected]?

Just give me a sec.....

Thanks....

-- supress unnecessary serial port messages for "file not found" from kftpd

Thanks Mark! Also, I was going to ask you if hijack uses any memory cache for ftp uploads or if they are written directly to disk? If not, a couple of kilobytes of cache might speed up the playlist fid uploads significantly.

-Mike

kftpd buffers the files somewhat in memory, and writes them to disk through the kernel block I/O layer. Note that the kernel itself performs disc caching, removing any need for the application (kftpd) to reinvent the wheel.

However, the kftpd code does currently do a "sys_fsync()" at the end of each file upload, which pauses service until the current file has been committed to disc -- perhaps that line could be removed, since a full "sys_sync()" happens on session termination anyway.

Presumably jemplode opens one FTP session, and keeps it open over multiple file xfers.. ?

Cheers

yep