Is it possible to mount the parttion with the mp3 on it? I have to delete some mp3 that got inadventantly shorted. Also, is there a command line program that can look for a bit rate say lower than 128 and delete that song ?

Thanks

Alan

Why can't you delete the files using emplode or emptool? You can mount the music partition but the files are not stored using their original names and this could be confusing.

The next version of emplode has a comprehensive search feature that will allow you to identify tracks below a certain bitrate, or tracks you dont listen to much, and thousands of other such criteria.

Rob

rob. actually its probably alright if they dont have their original name. I need to delete ones that are shorted. These should appear as 1 or 2 megs. How do I mount the partition through the hyperterminal?

Alan

I think I see what you're asking...

You had some failed uploads, right, and you want to delete the files that are too short because those are the bad files? Okay...

First of all, if you've cleaned out all the "Unattached items" and the files are still taking up disk space (i.e., they aren't in the database but they are still occupying space on the disk), don't worry. Those files will be overwritten later when you send more files to the Empeg. I had a couple of songs like that, and they simply disappeared as I filled up the disk.

You can hand-delete the files if it's absolutely necessary. But if the songs still show up in the database, then delete the files with Emplode instead. It will make the database much happier.

Now, if you're sure you want to delete the files by hand, here is how to do it:

- Use Emplode to export your database to CSV.

- Connect with Hyperterminal and q to a shell prompt.

- cd /drive0/fids

- ls -l

- Those are your files. (If you have two disk drives, there are also some in /drive1/fids, so look there, too.)

- The files ending in 0 are the MP3 files, the ones ending in 1 are the database information files. Just because a file is short doesn't mean it's bad, it might be a playlist or something. So cross-reference this list to the CSV you just exported. Be very careful not to delete the wrong files or you'll screw up the database and possibly lose your music.

- Once you're absolutely sure you want to delete stuff...

- Enter rwm to read-write mount the hard disk.

- rm the files you don't want.

- Don't forge this step: rom to read-only mount the hard disks. This is important!

- exit back to the player.

- Do some synchs with Emplode to make sure the database is OK.

___________
Tony Fabris

...and thousands of other such criteria.

Thousands?

tanstaafl.



"There Ain't No Such Thing As A Free Lunch"

Thousands?

Don't touch that one, Rob. He's going to ask you to calculate the actual number of possible permutations for a multi-parameter search. Then he'll come up with his own calculations to refute yours, and... well... we've seen this sort of thing happen on the BBS before. It's not pretty.



___________
Tony Fabris

Hehe you're right, and I don't know exactly how many fields and operators there are so I couldn't calculate it anyway.

Sufficed to say, it's a pretty useful search facility.

Rob

Tony,
On a related note, I've copied my fids from an older drive to another newer one thinking they would resync on restart (per the FAQ). When I take out the original drive and install a different drive (primary) drive, these fids on the secondary don't seem to be recognized.

Repeated syncs/power cycles don't seem to make a difference?

Any suggestions?

When I take out the original drive and install a different drive (primary) drive, these fids on the secondary don't seem to be recognized.

I don't know what's going on there, but the FAQ only talks about copying the fids to your replacement primary drive. You're talking about using an already-populated secondary drive, something I never tried.

I assume that your new primary drive is empty (except for the OS and player software), right? If not, if it's got song files on it, then you've probably got conflicting FIDs between drive0 and drive1 and that's your problem.

If it is empty, and it's got the space, then I'd suggest copying all the FIDs to drive0 and wiping them off of drive1. Then it all should work.

___________
Tony Fabris

Of course. I should have thought of that. Thanks.

I assume that your new primary drive is empty (except for the OS and player software), right? If not, if it's got song files on it, then you've probably got conflicting FIDs between drive0 and drive1 and that's your problem.

If it is empty, and it's got the space, then I'd suggest copying all the FIDs to drive0 and wiping them off of drive1. Then it all should work

No need to copy the fids to drive0 -- you can safely leave them on drive1 -- but do make sure there aren't any conflicts and killing any new ones on drive0 while 'importing' a consistent set using a new drive seems a safe way ensuring this. When there are no fids on drive0, rebuilding the database happily recovers all songs and playlistinfo on drive1; thereafter new songs are allocated to the drive with the most space.

I used this method to move all my somgs from the Mk1 to Mk2 -- it worked without a hitch

Henno
mk2 6 nr 6

When there are no fids on drive0, rebuilding the database happily recovers all songs and playlistinfo on drive1; thereafter new songs are allocated to the drive with the most space.

I thought that's the way it worked, too. But he said when he did that, the songs from drive1 did not appear in Emplode. That's why I suggested copying them to drive0. I thought perhaps that would fix the problem.

___________
Tony Fabris

After a while, the fid allocation stablises such that the *0 file ends up on one disk, and the *1 file ends up on the other. This, then, requires that you move the disks around as a pair. Tony's suggestion of moving everything onto the same disk would solve this problem.


Roger - not necessarily speaking for empeg