I just got my 60GB Rio player and I probably will have a few posts with some of the things I'm not too happy about. Don't get me wrong,.. overall the player is awesome and there is nothing like it on the market. But I think unless I write some better tools or find some, it will be a nightmare keeping my collection of mp3's on my home jukebox in sync with my player.

Here is the deal. I have *a lot* of mp3's. I actually slimmed down my collection from about 12,000 files to around 3,800 that I have put on the Rio. The other 8,000 files are not on my home jukebox but on a server at work. I am only concerned with keeping the home jukebox in sync with the Rio. The directory that I need to sync with the Rio follows a *very* strict format. All (almost all) of my files are ripped and encoded by me so the tags, bitrate and naming are very strict and enforced by my scripts that run on my home jukebox. Everything is really driven by a mysql database and perl scripts and it's really not important here. What is important is that I can see no way with either emplode or emptool to keep the player and my mp3 directories in sync.

My directories look like this

/mp3/o/Oasis/What's The Story Morning Glory/Oasis - Wonderwall.mp3

The top level directory /mp3 is just the mount point. Next are a series of 0-9a-z directories. To correspond to the first letter or number of the artist name. The scripts make sure the 'Til Tuesday get's stuck in the "t" directory and that "3 Doors Down" get stuck in the "3" directory.

So immediatley when I got the player I wasted no time to get my whole collection on there. I poked around in emplode for a few minutes and then came to the conclusion it was braindead in that it had no way of specifying a top level directory to grab all the mp3's from. I later figured out that I probably could have dragged and dropped the 0-9a-z directories on the hokey emplode window. Anyway, I found out that the emplode tool had an upload command with the -r (recursive) option so I used this. I think it was something like:

upload -r "/mp3/*"

The emptool chugged away for a few seconds,.. blurted a whole bunch of screenfulls of filenames and then sat waiting for a new command. I braced myself,.. entered the sync command and sat and watched for a few minutes. 30+ hours later the files were done. Now comes the hard part.

I buy new cd's every week and almost daily for more than 2 years now, I will normally add new mp3 files on my home jukebox. That's right. Every single day I add files to my jukebox. Sometimes it's ripping another track off a previously ripped CD or ripping a new CD all together. Either way,.. I rarely rip entire CD's, usually just the songs I like.

Neither emptool or emplode seem very adept at handling the task of keeping the Rio in sync with my mp3 directory. When ripping 50 songs on 50 different CD's,.. is it expected that I will poke around in my directories and individually select 50 different songs and put them in their proper directories in emplode? I think that sounds like a major pain. It would be much easier to just select the top level mp3 directory and the tool would know to grab anything that's not already in the Rio and transfer it. emptool doesn't seem to be any better at this. Not only that but emptool doesn't seem to be very scriptable,.. not without using expect or some crufty 2 way filehandles from Perl.

In any case there has to be people out there who have figured out how to keep their mp3 directory synced with the player. Taking suggestions, code examples, flames and whatever else you can send my way.

Thanks, Aaron Newsome

[stop the technology madness]

Right now, you can just drag and drop the parent directories into Emplode and it'll upload the whole thing for you, in one huge operation.

If you drag the whole thing a second time, then the problem is that it'll make a second copy of everything, which is what you don't want.

But the good news is that version 1.1, due out soon, will do dupe-checking on uploads, so that when you add new albums it'll allow you to drag the whole thing and it'll upload just the new albums, skipping the duped ones. At least, I think it'll do that, that was the plan as I recall.

In the meantime, you can simply drag the individual new albums onto emplode every time you buy a new CD. That's what I do. In practice, this isn't really that hard, it takes only a few minutes to locate my new albums, drop them onto emplode, and do a synch.

___________
Tony Fabris

Well,.. that's what I tried this weekend. Using the drag and drop method, hoping emplode would figure out what is duped and what's new. It didn't work, even worse it created a new top level directory.

After ripping a few more tracks from the Creed - Human Clay CD, I dragged the "c" directory from my collection onto emplode. Not only did it dupe all the artists inside the c directory,.. but it made a new toplevel "C" directory !!!! Changed the case and,.. blip!,.. just made a new one. I can see this isn't gonna work out.

There must be someone out there who has run into the same difficulties with keeping their collections synced. I ripped about 15 tracks yesterday in in a rush I left out a few of the tracks in my (very tedious) manual update process. A scriptable procedure would probably work better than someone elses interface idea of how to keep the two synced.

I'll put a developer image on the unit log into it and see if there is anyway I can figure it out. If anyone has had some success here, please pass along your story.

[stop the technology madness]

1st, I have no idea how the 'upload' tool works, so this might not be
feasible...

Write a script which uses find (I love the tools from cygnus,
http://sources.redhat.com/cygwin/)
to locate all files in the jukebox created after the last time you
synced, (create a timestamp file in the process) then use the output
to have 'upload' upload the found files to the proper directory.

As Tony said, the functionality will probably be in 1.1 - but it will
probably also not (as the suggestion above) handle stuff you remove
from the 'master'.

/Michael

This is what I think I have decided to do for now. Since all mp3's are in mysql I'll write a perl script to select * mp3 with mp3Id > 12345,.. where 12345 is the highest number synced with the player. Only problem is I'll have to experiment with the emptool (which has the upload command in it) because it is no a "command line" tool perse,.. but more of a command shell,.. with no apparent way of controlling it in a batch fashion. If worse comes to worse,.. I'll make my update script just dump out the upload commands to use in emptool and while in X windows running the emptool I can just copy and paste the commands. Anything less than a few hundred commmands and I guess it should be ok. But man will it be hokey,.. it'll have to do all the cd (change directory) and mklist commands seperately since when using -r (recursive) upload, all bets are off when the directory already exists on the Rio.

Thanks, Aaron Newsome

[stop the technology madness]

You could always download the emptool source code and change it to meet your needs.

Oh, and congratulations on your new toy.

The perl scripts I use run emptool twice. Once to get the status of the player ("ls -lr /") and once to actually upload all the data (that way I don't need two way piping). I compare file sizes to figure out if there has been a change on the PC (maybe I've reripped a file or something). The scripts do all the "mklist" stuff that needs doing.

It seems to work OK.

Richard.

Perhaps it was not clear from Richard's post: emptool will read its commands from standard input, of course. So, instead of cut-and-pasting, just pipe your command script into emptool.

So perhaps something like this will do:
- Touch a timestamp file after each sync
- Obtain fresh 'ls -lR /' listing from emptool
- Use find to make a list of tunes newer than timestamp file
- Create upload script, using the player content listing to figure out necessary make list commands and to distinguish between new tunes and updated ones (which will have to be deleted from the player first)
- Finally, you could compare the whole player listing to that of your reference PC to find out which tunes and/or lists need just deleting from the player

Keep in mind that emptool will not report original tune filenames, but will use song titles instead.

(This is an example of superiority of command-line over visual tools .)

Good luck!

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

You might want to check out jempeg by mschrag and dzimmerman. It is a java clone of Emplode. It is not perfect, but it will allow you to drag and drool your whole mp3 directory over and figure out what files are new and only upload the new ones. It has some ID3 tag issues, but asside from that it works pretty well. It is also open source so you can tweak it to meet your needs.

-Mike

Since you seem pretty adept at scripting, and have mysql running -- how about using that mysql database to your advantage? Use 'Expect' to control emptool, and get a complete listing from the empeg database ('ls -r' as I recall). You could use that as input to a 'player' table in mysql; then join the player table with your jukebox table looking for the appropriate instances of NULL (or date/time, or whatever) to figure out which mp3's to add or remove from the player. Adding or removing mp3's could, again, use the Expect/emptool combination.

emplode 1.0 doesn't do what you want; emplode 1.1 *does* do what you want. It dupe checks on various things including ID3 tags ISTR.

Hugo

upload -r "/mp3/*"

In any case there has to be people out there who have figured out how to keep their mp3 directory synced with the player. Taking suggestions, code examples, flames and whatever else you can send my way.

upload -p -r /mp3/*

Does exactly what you want, for the simple reason that that's exactly what I wanted when I added that feature.

Peter

Hmm, maybe it's time I slap some extra hard drive space into my Linux machine for all my music. I guess I never realised how flexible emptool was.

Yea, I think if you're using Linux, there are probably any number of ways to script what you want to do, including getting the CSV database and using it to drive a syncronization script that meets your needs

One thing that I need to get to scripting or figuring out, is a way to automate the creation of playlists for me so that if I ever have to rebuild my Empeg HD again with all the music, I can run a script to rebuild all my secondary playlists.

Also, since there is currently no way to make secondary links to folders the way I want it to happen, I need to either modify Emplode or Jempeg to do what I want. Right now, if you copy a folder in Emplode, let's say a particular album...into a larger secondary playlist... It does NOT copy or make seconary links to the mp3 files or whatever is underneath it. It simply makes a link to the containing folder. So that from the secondary playlist if you were to remove one of the mp3 files from that copied folder, the mp3 file would also get removed from the original folder. That's not that I want. I want to be able to drag an entire hierarchy of folders and copy them into a secondary playlist such that every subfolder gets copied as well, and every mp3 file within that hierarchy gets copied as a seperate reference to the same underlying mp3 file.

Hi.

I have/had a similar problem like yours. I have all my MP3 Files ripped from my Discs organized in a MySQL Database as well.

Because i was unable to find a complete solution that fits my needs, i started to write my own Perl script based on hints from this BBS or somewhere else after christmas.

I control emptool (tested only with 2.00-beta7) using a two way pipe from my Perl script.
I've just completed a first version of that script that seem to work quite well (inclusive matching the existing tunes with the database based on filesize and tracknumber).

The script depends havily on my database scheme and the way i organize my MP3s, but shouldn't be impossible to adapt for similar needs (even my code is more or less ugly).

If there is an interest in that script, i will put it online.

Happy new year,
Roli Alder

Is there anything I can add to JEmplode that would make it easier to manage this? Right now like Mike Comb mentioned, if you repeatedly upload/drag-n-drop a directory into JEmplode, it will remove duplicates. If there are specific modifications to that mechanism that would make it easier for you, let me know and we can try to work it into an upcoming release.

Mike

If there is an interest in that script, i will put it online.

There is always interest in such things, so please do put it online (and also post it on riocar.org).

Speaking of things you JEmplode guys could do to make out life easier, how about slapping together a quick-and-dirty cloning utility (as the 'official' one not always works, and I guess almost all new prout owners of 30GB and 60GB units need it)? It should, first of all, copy all FID files from source to target. It would be very nice if it could then trigger database-rebuild, too. Other niceties, like clonig the rest of filesystem and that non-FS partition would probably take too much time (if feasible at all) and are not that necessary.

I think this should be pretty easy ... when my two shiny new Empegs show up, I'll try to write this.

I think this should be pretty easy

You may be thinking this already, but rather than writing a whole new tool it would be cool to add the functionality to JEmplode to allow it to open two empegs and copy arbitrary files/folders between the two.

-Mike

I was thinking something like this ... Currently there is an FIDLocalFile that gets inserted into the database as a stub in JEmplode until you sync... I was thinking of making a new FIDCloneFile that contains a ProtocolClient and FID # of a remote FID on a remote Empeg... when you sync, it would then read the FID from the first Empeg and write it to the second ... This is kind of preliminary, but I'm tossing the idea around ...

So the way this works is you start Emplode and select a connection. There is now a new File Menu entry called "Open Clone..." that will open a second Emplode window. You can then select a second connection. The two Emplodes share a common clipboard, so you can copy and paste playlists and tunes across the two devices and sync them. The syncing will actually be direct Empeg-to-Empeg (i.e. it will read the Tune off the first Empeg and write it straight onto the second Empeg). Kind of cool :) It uses serial no's + FID's to create a new tag that is a Global FID. This is used to maintain reference counting across multiple Empegs. What that means is that multiple people can share tunes and they will all be reference counted properly among the group. The only thing that isn't tracked right now is if someone actually _modifies_ a reference counted playlist (i.e. the other people will think they have the playlist and won't get that new tune) -- however, you can copy and paste just the new tune into the reference counted playlist. Things are cleaned up a bit too so each Emplode window operates independently, so you can actually copy and paste both directions and then sync each Empeg seperately. Hopefully my second empeg will arrive tomrrow so I can test this out more thoroughly (in the meantime, I'm syncing _very slowly_ to a friend's across the Internet, which is really slick, I might add).

Mike

Great! Exactly what we need, and it will be ready when I finally receive my second empeg (thanks to slowness of our customs)...

A suggestion. It doesn't have to be an exact clone. You might want to pick specific playlists and copy them and their associated tunes over. (e.g. if you're going from a bigger to smaller empeg)

Calvin

Yep -- that's how it works... I have a message in this thread up above that has more details...

There's a post in the Programming forum if you want to try out the alpha version of JEmplode's cloning support....

I would like to, but my second empeg hasn't shipped yet...