Hi,

More information...

Mark asked:

I would assume that means he tried to transfer 120 mb of music to the empeg via emplode.


I might assume that too, but I'd really like know.
And it might be useful to know at what stage the thing dies -- during the file transfers, or during the database build ?


Answer:

Yes it was 120MB of song database load through emplode. Mark has a valid point, I do weird things sometimes. <grin>

I hope what is listed below might help with his second question.
*****************************************************************

strace information
------------------
I was able to get strace to work. What I hadn't realized is that I needed to tell it where strace was. I decided to put strace in the root of drive0 (I thought it would run from the root of the empeg, I thought wrong). When I looked at the contents of the log file, it kept saying it was a bad command. As soon as I pointed to where strace was, as in ./strace ...., it worked. The log file does quickly fill with LOTS of data with the system call data. Dumb mistake, I know.

Unfortunately, as soon as I used it, in emplode, it needed to perform a Check on the Media. Without strace, it doesn't need to. Even on known good drives with fully rebuilt media (doesn't matter the size - 250GB or 500GB or interface type - EIDE or SATA), needs 2 passes to go through it, and dies. This included a drive with and without song database, all drives had been fixed for the missing tags and include the rom lock. I can re-create a log file if you need it.



So... I wanted to find out if it is a software or hardware problem. Now that I have a better understanding of ftp (didn't know it had the capability or how to use it a couple of days ago), I was able to get a better definition of what works and what doesn't.


I prepared a 250GB EIDE drive and placed 1GB of song database on it through emplode. I then opened an ftp session with the player, directed to the fids on drive0 and changed to an ftp session in Windows. I created a directory for the fids on my PC and copied the fids database from the player to the new fids directory on my PC. That obviously took a few minutes to do.

I then changed out the player drive, built a new drive on the player (put in the 500 GB SATA interfaced drive), opened a HyperTerm, quit the player software, made the music read/writable (RWM), and exited. I know this is dangerous, but, this is all development anyway.

I opened an ftp session in Windows and copied about 350MB of the fids database from the Windows directory into the drive0/fids directory. This took some time as well. After the copy completed, I mounted the drive (mount -n -o remount,rw,nocheck /drive0 - probably not neccessary at this point), CTRL^D to force a rebuild, Ctrl^C to stop it, and rom to lock.

It worked! The player has all that I down loaded, the structure is correct. It operates normally.

So I am able to copy large files across the SATA Adapter through an ftp session onto a 500 GB drive which points to some kind of other problem. Not a full fuzzy that the hardware path works but it helps define the problem more.


I could run strace in the ftp session if you want it as well.


What do you think?

Thanks,

Ross
_________________________
In SI, a little termination and attention to layout goes a long way. In EMC, without SI, you'll spend 80% of the effort on the last 3dB.