I have just released mp3tofid 2.00 which can be downloaded through riocar.org

It's almost completely rewritten since the initial version 1.00.
The biggest differences I can think of now are

• creation of player database (database, playlists and tags)
• hence no longer dependent on Emplode
• built using libid3tag instead of id3lib
• hence now written in plain C rather than pseudo C++
• compensation support for broken second drives (mine was during development)
• speed improvements
  

Unfortunately, the FID's created by this release are not compatible with the previous version, which will make rsync do a complete upload after switching to this release of mp3tofid.

There's no cygwin (ie. Windows) port for this release; it turns out the symbolic link emulation in cygwin is very adequate, but the inode emulation is not, and will require extra coding. I decided to release what I have now, and postpone the Windows port to a future release.

Pim

Is it possible that this utility might help this person in any way?

I might be comparing apples and oranges since I don't know exactly how this stuff works, it was just a thought.

Not really. Switching from (j)emplode to mp3tofid/rsync will initially force a complete upload anyway. (switching back will not).

Once you are using mp3tofid and rsync, you may be able to merge FTP'ed tunes by cleverly renaming them on the player, provided you have the tunes on your host PC as well.

But the whole idea of using mp3tofid with rsync is maintaining an exact clone of what's on your host PC. So it would normally just delete anything you have uploaded using FTP.

Pim

Pim

say you've been using this util. what happens if you mark something on the player.... will that be gone as soon as you rsync?

What do you mean with "mark something"?

If you mean: what happens if I use mp3tofid/rsync, then upload someting with emplode, and then again with mp3tofid/rsync, then the answer is:

You lose all the changes you made with emplode.

But if you add your newly uploaded tune to your source tree on your host PC as well, it will be re-uploaded, but very likely with a different FID number. If you manage to rename your new tune on the player so it gets the same FID number as mp3tofid thinks it should have, then rsync will not have to re-upload the tune.

Needless to say, mp3tofid/rsync are best used exclusively in order to be of any use.

You can easily try mp3tofid "running dry". Nothing happens on your player until you use rsync to actually transfer the data. Add something to your source tree, or change some ID3 tags and see how mp3tofid notices.

Pim

I thought he meant "mark something" as in "press the MARK button on the rio remote control". I could be wrong.

yeah, thats what i meant.... the MARK button on the remote... if i recall, isnt this stored on the custom scratch partition.. and it records the FID, so i guess that i'll still be able to use it for its main function... to delete songs i hate. speaking of which, won't the rsync method expose us to the "reused fids" bug?

so anyway, mark songs i need to take off my player, use emplode to see which ones, then just delete it from the main tree. but what happens if i decide to upload my friends collection to my empeg... no way to rsync back.... so i'd use jemplode to download to my drive, then rsync back. heh.

hmm. this should work well. hope you get the windows version soon. or mebbe i'll just install virtualpc and debian. been a while since i've installed linux. yikes.

In reply to:

---

the MARK button on the remote... if i recall, isnt this stored on the custom scratch partition..

---

Most likely, it is recorded in the scratch partition. No way the player will mount your drives read/write just to record this button press. Storing this info in flash could be possible, but is unlikely too.

In reply to:

---

won't the rsync method expose us to the "reused fids" bug?

---

Yes, probably. But both emplode and mp3tofid will reuse FID numbers, so this is inevitable. If FID's would not be reused, the database file would grow and grow, and the player would consume all memory to read it.

Now if only more was known where what is stored in the scratch partition...

can someone help me w/ debian and smbmount? i did a base install, then apt-get install smbfs, but everytime i try to do a mount.smbfs, it gives me a filesystem not supported by kernel. do i really have to recompile the kernel for this?

Yes, probably.

ok, after playing around with this on linux in virtualpc ... i must say that this accessory is REALLY COOL. i was able to avoid the reused fid bug by doing a clean install using the builder kernel. i hope you're going to release the windows version soon. emulating linux to do this takes way too long.

a few suggestions.... when generating playlists... can you follow symbolic links/shortcut instead of strictly directory structure? i.e. if i had a shortcut to a folder, that would become a new playlist, and a shortcut to a file becomes a reference in the current folder. also, while i did manage to avoid reused fids initially... i'm not sure if i delete a song, will the next song added use the same fid. i'd like to see a temp file w/ the last used fid used, and have it used and incremented. but from your post..are you saying that if i had 2 files.. with fids on the extreme sides of the range.. it will maximise the database file?

I finally had time to try this out (1.00 crashed for me). 2.00 makes it through the runs just fine now. How big should the database be? I don't remember how big the emplode/player created one was, but for 9 gigs of mp3s, mp3tofid is creating a 670 meg database which seems excessive. I did sync all my mp3s to my empeg last night after reloading it from scratch (just to make sure), and the player now crashes on startup (out of memory I believe). I deleted the database to see if it would recreate it's own, and the same thing happened.

I am using a single drive empeg (so I do a "-2 0" on the command line). I wondered if that was causing the database to be so huge so I ran just a plain old -Ii run and the database was the same size. I am not sure what to do next. I haven't tried getting emplode to connect to it, but I doubt it will with the player software crashing.

What's you highest inode number? You can find out using

find /your/mp3/dir -printf "%i %p\n" | sort -n"

mp3tofid calculates the fid number from the inode number (inode number + 18) of the source tune. This way, the fid number stays the same, even if you rename or move your source tunes.

I store my mp3 files in a dedicated reiserfs filesystem. I don't know about ext2, but reiserfs allocates inode numbers from one up. If your filesystem does not, your inode numbers might not be consecutive. If you share the filesystem with other stuff, there will be lots of unused fid numbers between your lowest and your highest fid number.

The player database contains one byte for each nonexisting fid number up to the highest number. So high inode numbers result in a large player database.

This makes it impossibe for now to port mp3tofid to cygwin, as its inode numbers in cygwin appear as random 32 bit unsigned integers. This would result in a player database larger than the maximum filesize for most filesystems (2GB).

But your inode numbers might be too high too.

To fix this, I will probably have to create a separate database that tracks inode numbers to fid numbers intelligently. I'm looking into gdbm whether this does what I want.

Pim

smbfs is not usable for mp3tofid. It looks like smbfs fakes inode numbers inconsistently across mounts.

Pim

can you follow symbolic links/shortcut instead of strictly directory structure?

That's exactly what mp3tofid does. You can create hard links to tunes and
soft links to tunes and directories, and mp3tofid will follow them
intelligently (better to use soft links than hard links, though).

But you need a native unix filesystem to create hard links or symbolic links.

cygwin can emulate symbolic links on windows nicely using windows shortcuts, but has a (so far)
unusable inode emulation.

i'm not sure if i delete a song, will the next song added use the same fid.

That's up to the filesystem. Will it reuse the inode number, than the fid number
will be reused too. But that's really not a problem for mp3tofid or rsync.
The new tune might inherit the playcount of a deleted tune on the player,
but that happens with emplode too.

are you saying that if i had 2 files.. with fids on the extreme sides of the range.. it will maximise the database file?

Yes, every nonexisting fid number in between takes one byte.

Pim

Boy, as soon as you mentioned inode number, the lightbulb went off in my head. Just for fun, I checked and my lowest mp3 inode is 376218 and my highest is 693902805.

I use XFS, it allocates inodes rather aggressively on the fly.. And this isn't a dedicated filesystem for music.

So, I guess I'm hosed for now. I'll re-upload all my music with emplode and keep watching this project..

Thanks, and I really do appreciate your efforts.