Hi!

I've update my Empeg with a second HD yesterday (IBM 48gig). This was not as easy as I would have figured, but after some fiddling around it worked. (see the Need some help with upgrading with 2nd HD thread.

Ok, now the time had come to upload all the mp3 files. All 46gig of them.
I uploaded in two batches : a batch of 14 gig yesterday, which worked flawlessly. Today I wanted to upload the rest. I started the empeg at 06 am this morning and went off to work. I came back at 4pm and it was still synching. At about 7pm, the empeg turned noticably slower. The led of my pc's HD flashed only occasionally anymore, while at first it flashed constantly. At 7:30pm Emplode stopped uploding, providing an error : Synch process failed during stage 5 : player error 0xffffff92. The empeg itself stays in "synch mode" and can't be accessed anymore.

I looked this up in Roger's synchonisation error table and - If I did everything correctly - this should be error #110 (Connection timed out)

I've tried this two times, once with ethernet, once with USB. Same.
Uploading ONE file now takes 10 minutes, but at the end the synch process fails. After a lot of time rebuilding the database, the file doesn't even show up in the list.

All files that were already uploaded play fine however.

What may be causing this? I've still got 19gig of free space left (according to emplode), AND I've still got about 10gig of files left to upload.

Please help!

Thanks!



Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

What may be causing this? I've still got 19gig of free space left (according to emplode), AND I've still got about 10gig of files left to upload.

Hm, this probably doesn't have anything to do with your problem, but check for free space from Linux (this assumes you have development image installed):

Connect via serial, quit the player (type q ), then type this cryptic line (the player lacks a certain file necessary for normal 'show free space' command - df - to work):
/sbin/df `echo \`cat /proc/mounts | sed "s/ [^/].*$//" | sed "s/^.* //"\`` 2>/dev/null
(all in one line, enter only at the end - the command will probably wrap to the next physical line).

(In the case you are wondering, this means 'Take file /proc/mounts, delete everything from the blank following the rightmost slash (if any) to the end in each line, also delete beginning of each line up to and including the first blank, feed the result to df command, display normal output, discard error messages'.)

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

Er, I am stupid. You just have three filesystems to chack, so no need for that mile long command.

Simply write
/sbin/df /
/sbin/df /drive0
/sbin/df /drive1

Sorry for complicating without need...


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

OK, I've used those commands you said. this is the result :

q
Restored terminal settings
Remounting first music partition read-only
Remounting second music partition read-only
Player exited normally: 0
Switching to shell-player loop
Starting bash.
empeg:/empeg/bin# /sbin/df /
/sbin/df: Warning: cannot read table of mounted filesystems: No such file or dir
ectory
Filesystem 1k-blocks Used Available Use% Mounted on
- 15863 6191 9672 39% /
empeg:/empeg/bin# /sbin/df /drive0
/sbin/df: Warning: cannot read table of mounted filesystems: No such file or dir
ectory
Filesystem 1k-blocks Used Available Use% Mounted on
- 46039044 36314096 7386288 83% /drive0
empeg:/empeg/bin# /sbin/df /drive1
/sbin/df: Warning: cannot read table of mounted filesystems: No such file or dir
ectory
Filesystem 1k-blocks Used Available Use% Mounted on
- 9727008 372 9726636 0% /drive1
empeg:/empeg/bin#

Does this tell you anything?

Could this have something to do with the new HD? I see that the smaller 10gig is still completely empty. Is there a way to perform a stress-test on the HD from the command line. (as you may remember, the disk.builder program never got far enough to begin this stress-test)

Thx!

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

I've tried again this morning, figuring I couldn't loose. I added the same files and directories to the empeg via the same method in Emplode.

Guess what? It worked.

?????? What has changed now??? The only thing I can think off is that the player, after 14hrs of continuously uploading files got too warm or something and freaked out.

I'm happy that the problem is solved, but I stil think it's very strange though....

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

UPDATE :

Ooops, nevermind what I've just wrote, emplode's acting up again. It uploaded +/- 40files at a good speed, but now has slowed down considerably.
To give an indication : it takes +/- 3mins for ONE 13Mb file.
It's still going, but I expect it to crap out on me any minute now. So I guess my problem isn't solved anyway.

Anybody else ever experienced this?

UPDATE :

As I've expected, the unit did crap out on me. It went through all the 'to upload' files (an took it's fair amount of time too - 3hrs to upload the contents of 6cd's, mp3 format that is - that's what? 420Mb?), but it failed with the same synch error in the end. The result is that some of the uploaded files got through, others didn't. There seems to be no pattern in the order of which the files either got through or were rejected.

I can't help but wonder if something didn't go wrong when I manually formatted the drive and added some directories when the builder.upgrade file failed halfway. Maybe I forgot something? (a drirectory, a partition that didn't get formatted?)

If nobody can provide me with a resolution, I guess I'll re-do the whole thing, but I'll put the 10gig as master and the 48gig as slave then. I'll use the procedure Bonzi suggested, avoiding the usage of the disk.builder image alltogether.

Could someone @empeg (or anyone else for that matter) PLEASE help me with this, 'cause it's driving me crazy!

And yet another update :

I've tried this again : I've powered down the Empeg and let it cool off for 3hrs. When I turned it back on, I could use Emplode and upload files to it like it was supposed to work.

After +/- 30 files, the machine became gradually slower, until it timed out with the by now well known error.

So this whole problem seems like a heat problem. Is this possible? Is this a first? And what's overheating here? The electronics on the motherboad of the empeg, or the added IBM drive?
Also, keep in mind that the Empeg does keeps on working perfectly : it still plays mp3's great, it's just the adding of files that gets screwed up.

I did not do anything special to it when I added the second drive. Just inserted it and closed the empeg up again. I'm sure I didn't damage anything, I was way too careful for that.
Also, there is certainly nothing blocking airflow.
I can't understand why this is happening

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

It is unlikely to be a heat issue. More likely, it's something about that second drive. If you had no trouble before adding the second drive, but you have trouble now, that would be the logical conclusion.

Have you tried contacting support?

___________
Tony Fabris

This has just confirmed that emplode is right and you really have some 17GB free. Not that it helped...

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

As Tony said, the only thing that changed is the new disk. I don't think that anything you did to it might have resulted in this strange bahaviour. If you make an error in partitioning, formatting etc, it just does not work.

Now, the disk could be having thermal problems. Try rebooting the player, letting it work (play) for several hours, then try to upload something. If the disk indeed has problems with thermal recalibration or something like that, it should show with the first files transferred.

Another thing: switch the drive activity icon display and see whether it seems to be on longer when the drive is warm. To switch the icon on, add
[display]
caching=1
to /empeg/var/config.ini if it is not already there. To do that without the editor, do the following:

Drop to shell.

cd /empeg/var

car config.ini or more config.ini to see whether the option (and section) you need is there

If it is not, type
rw
rwm
cp config.ini config.safe
echo '[display]' >> config.ini
echo 'caching=1' >> config.ini

Remount read-only (ro) and return to the player (exit).


But, this all is shooting in the dark. Have you contacted support? What do they say?

Good luck!


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

There's a much simpler way to turn on the drive icon. Emplode has a check box for it in the Configure Player screen.

___________
Tony Fabris

Ahem, too much time with emptool, I suppose .

This is the second time in one thread I gave an advice at least an orders of magnitude more complicated than necessary.

Some things are best left to Tony.

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

Tony,

I tend to agree with you, but I wonder then how it is possible that the disk worked fine for 13hrs straight uploading, and then all of a sudden started showing this behaviour. (after being +/- 80% full). And from that moment on every single time in the first 15 minutes.
That's why I would like to know if there's a way to perform a stress test on this HD.
Is it possible that a HD starts showing heat related problems after a period of usage??

I might also try to open the player up again tomorrow and remove that 48gig, only using the 10gig (like it was). Normally that 10gig shouldn't have any problems with uploads. If the problems don't turn up in the first 30 minutes then I'll know for sure.
There is no way that incorrect formatting or adding of directories could make the harddisk work ok for about 80% and then start showing problems?
All I did after all was format the music partition and add two directories, but I don't remember which they were - PGrzelak advised me and I can't remember which they were. But I would think that if the disk works for 80%, it should work 100%!

Bonzi,

I've enabled the HD led, and I'll see what happens now. Because of the command you provided I've been able to see that the second disk has not been used yet. All files so far have been put on the first hd. I will try what you suggest today, and see what it does. I suspect that I will do exactly what you say it will do : the problem will show up faster, probably even in the very first transers.

I will contact tech support tomorrow, and see what they say. I haven't done so yet, because I figured I'd see what the people on the board had to say about it first.

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

Because of the command you provided I've been able to see that the second disk has not been used yet. All files so far have been put on the first hd.

I thought the empeg was supposed to balance the files across the two drives adding them to whichever had more available space? If that is true you should have files on the 10Gig drive at this point. Maybe the files that are disapearing are the ones that should be going to the 10Gig? If that is true it might explain why it worked fine for the first 13 hours, that was how long it took to fill the larger drive to the point that they both had the same amount of free space.

So maybe the empeg can't write to the smaller drive for some reason. Have you verified that after a rwm you can create a file by hand on the smaller drive?

-Mike

Greetings!

Sorry for the delay - busy weekend.

Heat should not be a factor, or at least it is not a factor for me.

It is possible that there is something going on with the drive, but what it is I do not know. The directories that you created were the /drive0/fids and the /drive0/var directories.

I can only guess that there could be some error on the hard drive, or an error on the filesystem that was created. What might be a possibility is to do an fsck on the hard disk. Try the following:

# rwm
# swapon /swapfile
# fsck /drive0 (Note: this may take a while...)
# swapoff /swapfile
# rom
# exit
- try another sync

This will do a file system analysis similar to scandisk under Windows. It should show any errors, and also clean up any errors on your disk. [disclaimer] This should help, but, like any analysis too, can cause damage as it tries to repair things. I have not seen it happen with this tool, but you never know. [/disclaimer].

This test is actually performed every 30? syncs, when emplode does its disk checking.

Paul G.
SN# 090000587 (96GB Smoke)
SN# 030103046 (10GB Blue - Emergency Spare)

Mcomb :

I've just tried what you've suggested, but looking into the drive1/fids directory now shows that there ARE files present. (I've been continuously uploading files to the player, if only half an hour at a time).
The sbin /df /drive1 command also shows 7% used.
I've tried manually copying a file from one HD to the other and this works no problem.

Paul,
I've tried those commands you've said. I think everything worked ok. This is what hypertrm showed :

Starting bash.
empeg:/empeg/bin# rwm
empeg:/empeg/bin# swapon /swapfile
Adding Swap: 16028k swap-space (priority -3)
empeg:/empeg/bin# fsck /drive0
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
/dev/hda4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda4: 10490/5849088 files (5.4% non-contiguous), 9447483/11693311 blocks
empeg:/empeg/bin# swapoff /swapfile
empeg:/empeg/bin# rom
empeg:/empeg/bin# exit
logout
Shell exit
Starting player
empeg-car 1.03.

Ok, so last night I went to bed, but I let the empeg play. When I got up this morning it had played for 9 hrs. I immediately fired up emplode and uploaded a file. The problem popped up immediately, convincing me more and more that this has something to do with heat.
The next thing I'll do now is open the player up again and only connect the 10gig drive. If my theory is correct this one should not have any problems with uploads.

I'll get back to you and will send an email to support@empeg while I'm at it.

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

Have you tried a ramtest when the player fails a sync?

Hugo

No, I haven't. I've just re-opened the player, and the 10gig works fine without the 48. the 48works fine without the 10 AND they work both fine together, OUTSIDE of the unit. Which does make me suspect more & more it's a heat issue. the fact that the player works fine otherwise is probably due to the fact that the drives are most of the time spun down while playing.

I will reassemble the player now and see if the error pops back up again. If it doesn then I'll perform a ramtest.

though I am now convinced it's a heat issue, I'm still puzzled as to why it worked for over 12hrs without a problem and then started to act up...

Update : I've been contacted by David from tech support who claims it's probably a faulty IDE cable. This is very well possible. He'll send me a new cable so I can solve this.
I'll get back to you guys with the result.

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

just a thought... and i mentioned this in another thread... AND i'm not sure if it would cause anything like this...

But are you sure the bottom of the drives are insulated from the sled and not making contact? Is there pressure on the spindles?




|| loren.cox ||

Thanks for the thought, but there isn't. I've put three washers on each screw. As a result, there is +/- 2mm space between the print circuit of the HD and the hd tray.

I'm now awaiting the new HD cable. I'm pretty much sure that that will solve the problem. I've taken a closer look at the cable and the connector seems somewhat loose. Probably because of my first attempt to remove the cable and realising too late that it was glued onto the Hd UNDERNEATH (not visible to the eye). Those cables really are much more sensitive than regular IDE cables or even SCSI cables.

I will post an update when the cable has arrived.

Thx!

Riocar 58gig (48gig + 10gig IBM travelstar) S/N : 10101747 red

In addition to the problems I had after updating my Mk2a with a IBM 48gig drive....

The new HD cable Empeg sent me didn't do much good : the problem persisted.

So I did some research on the problem (with the help of Pgrezelak - Thanks again Paul!) and this is what I came up with :

So what did I do : I copied all the files from my 10 gig to my 48gig. I then opened up the player and disconnected the 10 gig. I closed the player up again and tried a synch of 2 gig of files : Tadaaa! Worked!

I then tried using the 10gig as the masterdrive, and the 48gig as the slave (the 10gig still had 1.03 on it, it was the drive the unit shipped with). Closed the unit up again. Tried a synch. Didn't even get to the point where I could upload files. In the screen where the player rebuilds it's database because the HD layout has changed it locked up, showing error 10. The player itself didn't stay in "synch mode", buy ended the database rebuild and showed the "end of playlist" screen.

I opened the player up again and switched the harddisks' place on the connector (so that the master drive would be closest to the mainboard again. Again, synch failed, same error.

I reopened the player, removed the 10 gig : got a perfectly & fully functional unit.

So this is what it's like :

*only 10gig drive : works
*only 48gig drive : works
*48gig master + 10 gig slave : works for playing, but with the "heat lookalike problem" when uploading
*10gig master + 48gig slave : doesn't even make it through the first synch.

So I guess it's pretty safe to say these two drives don't like each other, though they're both IBM. In the not so distant future I'll buy a second 48gig hd, and if I'm correct, that should work without a problem.

I used v1.03 only, not 2.03 beta. The database file was deleted before a new synch was made.

Something good actually did come out of this : I can now replace a hd in my empeg blindfolded in less than 4 minutes! Not bad eh?

Anyway, thought you all may wanted to know this.

Something good actually did come out of this : I can now replace a hd in my empeg blindfolded in less than 4 minutes!

I'd like to see that!! make a video of it!

LOL! Well, the blindfolded part may be a little bit exaggerated, but I can do it in less than four minutes. I opened and closed it five times today I guess. After a while I got the hang of it!

Hmm.

Reading back on this thread, I have a question for you. All this time you've been having trouble with both drives plugged in, but not when it's just one of the two drives.

Um...

What power supply are you using?

Erm...The one that came with the Rio, why?

Okay, just checking.

It's still an interesting point, actually; were the syncs done with the empeg in standby (ie, display off) or display on?

Hugo

The Empeg was not in standby. The "end of playlist" message was on screen each time I did a synch. Does this make a difference? It sure doesn't when only one of the drives is in the unit. I must admit I haven't tried synching with the unit in standby yesterday, but I did during the last month when the Hd's were setup like 48g master, 10g slave and that didn't do any good for the problem. The "heat lookalike problem" persisted.

For now I'm working with only the 48gig in the unit, but I'll add a second 48gig drive to that because one 48gig is not enough for me. (actually I need about 3 gigs more, so the 10gig would have been perfect - bummer)

The "end of playlist" message was on screen each time I did a synch. Does this make a difference?

Interesting. Maybe. There was a known bug in 2.0b3 regarding the player not booting correctly with a blank playlist...

Erm yeah, but I haven't used 2.03b yet. I'm still using 1.03...