I've got a 60G unit and one of the 30G HDs has gone bad (It just clicks most of the time). I have already contacted support. The drive that's bad is Drive 1. If I remove it, the unit will boot and operate correctly. My question is: Do files get spread over BOTH drives normally, or only AFTER Drive 0 gets full? I have less than 30Gs of music, is it all stored on Drive 0, or is it spread over both drives? This will determine whether I've lost anything on the bad drive and if I can keep the unit running on Drive 0 until I get a replacement for Drive 1. The bad drive will boot up about 20% of the time, so if there are files on there that I need, I still may be able to salvage them.

Thanks,
Jeff

I am pretty sure that the files get stored on the drive with the most amount of free space. So most likely, probably half of your files are on each drive.

Oliver is correct. This is a FAQ entry:

How are the songs stored on a two-drive player?

Does anyone know how often the drive space determination is made? Between every track uploaded? Every ten tracks? Between playlists? Between syncs?

As far as I know, it's with each and every FID added to the player.

OK. It fills both drives up. Then why when I enable the "DRIVE" column under Jemplode, does it show all files including playlists as on drive 0?

Jeff

Assuming that half of my music is on one drive and half on the other, if I can get the flakey drive to last long enough, is there a way to copy the music over to the good drive? There's plenty of room. I'm guessing that copying just the FIDS is not going to do it...

Jeff

Then why when I enable the "DRIVE" column under Jemplode, does it show all files including playlists as on drive 0?

From that FAQ entry that I linked:

There is currently no way to tell which files are stored on which drive without fishing through the FIDs by hand at the shell prompt. Plans to implement a feature for this in Emplode have been cancelled. The player currently does not care whether a given song is on /drive0 or /drive1, and will search both drives for files when retrieving songs.

So Jemplode should not even allow that column to appear since it is unused. That should be reported as a bug to Mike.

if I can get the flakey drive to last long enough, is there a way to copy the music over to the good drive? There's plenty of room. I'm guessing that copying just the FIDS is not going to do it...

Actually, that's exactly what you would do: Copy the FIDs over to the other drive. Assuming, of course, that you can get the second drive to last long enough. You'd have to do a database rebuild, but after that, all should be well.

Question: Are you sure that you have a bad drive? Perhaps it's one of the other possible problems other than a bad drive.

Yes, It's definitely the drive. I've already replaced the IDE cable. This drive just clicks when hooked to either IDE connector, except sometimes it will spin up OK.

Jeff

OK, I copy the FIDs from drive 1 to drive 0 and rebuild the database. What is the best way to copy the files? FTP through Hijack? Shell into the unit and copy from one drive to the other? If the Shell method is the best, could someone help me with the commands to copy the FIDs?

Thanks,
Jeff

You'll need to install a developer image. Then, using a terminal application like Hyperterm, access the player via the serial port. Press `q' and hit return to get to a shell prompt. (You might have to do that a couple of times.) (Also, if you have any problems with those first few steps, you should be able to find further guidance in the FAQ.) Once there, type the following commands:

swapon /swapfile

cd /drive1/fids/

rwm

cp * /drive0/fids/

cd /drive0/var

rm database

rom

swapoff /swapfile

Then reboot the empeg and attach via emplode. Both of those steps will take much longer than normal. Sync and you should be good.

Please wait for someone to confirm these steps before you do them to make sure I've not screwed up somewhere.

If you have shell access to your empeg the fastest way is via a direct drive to drive copy.

But: You have to familiar with Linux/shell prompt and know how to get a shell prompt via the serial port - so you need that all working.

Assuming you do then this should do the trick. But, this method worked for me to move all songs/files from drive1 to drive0 on my 2 drive 60GB unit. Admittedly I only had about 7 GB on the second drive so it only took a few hours.

0. Get a shell prompt on your system via the com port. [this involves quiting/stopping the player program - the FAQ has info on this.

1. At the shell prompt enter this command to mount the drives read/write

rwm

2. Enter this command exactly as shown: (Cut and paste is your friend here :-)) )

(cd /drive1;tar cf - fids) | (cd /drive0;tar xf -)

[Nothing will show but your disks should start running, any errors equal bad news - you may see some if files cannot be copied across due to bad sectors on your drive1, it may take time to complete [expect it to take hours not minutes].
The copy may stop in this case - you will be able to restart the copy again(just enter the same ocmmand again) - the copy may fail [one or more time] if you disk is really near the end of its life.

You just have to keep trying - cooling the drive before the copy starts can help [stick the drive/empeg in the fridge beforehand if you find the drive works best from cold]. Protect the unit from moisture though!!!
YMMV - I have got data of drives that way by putting them in the freezer compartment while the drive is running (using long drive cables) - you'd be amazed sometimes what unreadable drives can be read that way.
Of course you must keep the ice [and melting ice] away from the electronics or bad karma will occur.

After copy completes:

3. Enter at the shell prompt: (cut'n'Paste recommended here too):

cd /empeg/var ; rwm ; rm tags database playlists

4. exit the shell /command prompt.

exit

[Player software will now resume]

5. Run Emplode and connect to the unit - it should force a rebuild of the database, with all songs as they were except now in the one drive.

6. Verify that your empeg is working properly

7. Remove the old failing disk from your system (follow the procedures in the FAQ for this). And/or return whole unit if under warranty.

cp * /drive0/fids/

If there are lots of fids, the * in that command will expand to too many characters for a command line (it's a kernel limitation). Number6's method using tar is thus a better bet.

(cd /drive1;tar cf - fids) | (cd /drive0;tar xf -)

If you change the xf to an xvf it will print each fid number as it copies it:

(cd /drive1;tar cf - fids) | (cd /drive0;tar xvf -)

Peter

Thanks all! Once again, the experts here have come through. I have sucessfully moved my music off of the bad drive and on to the good one without a hitch...

Jeff

I have sucessfully moved my music off of the bad drive and on to the good one without a hitch...

Ah, that's good news! It's still a Good Idea though to make sure the Empeg isn't the only copy of your music. If you didn't keep CD-R copies of everything when you stored it to your Empeg in the first place, you should back it all up via your PC now. Even good quality drives do occasionally fail and it's always bad to be only one spindle away from disaster.

Peter

Thanks for the recommendation. Actually I do have everything backed up so to speak. All of my music is also on a dedicated music server, that serves the mp3s to my Audiotrons scattered throughout the house. The problem is, I've done a better job of keeping my tags organized on my Empeg, than on the server. If there was a way to use jEmplode to properly download everything back to the server, that would be nice. I know you can download with either Emplode, or jEmplode, but I haven't been able to get either to extract folder names from the Artist/Album info in the tags. jEmplode seems to lump all of the songs under one folder with the artist's name and doesn't create album folders.

Jeff

If there was a way to use jEmplode to properly download everything back to the server, that would be nice. I know you can download with either Emplode, or jEmplode, but I haven't been able to get either to extract folder names from the Artist/Album info in the tags. jEmplode seems to lump all of the songs under one folder with the artist's name and doesn't create album folders.

The latest versions of Jemplode allow for you to specify exact file names for downloading, and you can even spec directory names simply by using backslashes in the filespec. After you grab them with Jemplode, you can tell MP3 Tag Studio to do a filenames-to-tags pass on the entire file group. For instance, in Jemplode options, I have it do the following file names:

{genre} - {artist} - {source} ({year}) - {pos:2} - {title}{ext}

Then, in MP3 Tag Studio, I do "Auto Tag From Filenames" with the following spec:

<Genre> - <Artist> - <Album> (<Year>) - <TrackNr> - <Title>.mp3

You have to be careful about what delimiters you use in the file names though. For instance, the delimiter I show above is space-dash-space, but that sometimes ends up in the artist name or the album name. So you might want to use a different delimiter. And of course, anything that's an illegal DOS character such as ? / < > : etc will become an underscore. Also, remember that if you want to use MP3 Tag Studio to do this, only the latest version (released within the last week) will allow you to use Genre in a filenames-to-tags pass.

Of course, it will be easiest when Jemplode gets tag-writing into its bag of tricks, and it can just write the tags to the files as it downloads them. Reportedly, this is coming soon.

Good point. On the other hand, I just did an ``ls *'' on mine and it dies if I don't add some swap, but seems to work fine if I do. Regardless, he probably has more FIDs than I do, and could easily hit that limitation.

I'd have suggested the tar thing if (1) I'd realized that the empeg had a tar on it and (2) I hadn't been rusty due to having been out of work as a Unix sysadmin for nearly a year now. (This marks the 4 millionth time I've mentioned I'm out of work.)

In reply to:

---

If you change the xf to an xvf it will print each fid number as it copies it:

(cd /drive1;tar cf - fids) | (cd /drive0;tar xvf -)

---

And you can avoid the two sub-shells and their cd's using tar's -C option:

tar c -C /drive1 -f - fids | tar x -C /drive0 -v -f -