Unfortunetly, increasing the drive size of my empeg was not as easy as I thought it would be. I have hit some roadblocks (hopefully more of detours) and I was looking for some advice from any one with the experience.

I filled my 80 gig empeg last year sometime, and I bought a 2nd matching 80 gig drive to double my space and allow more song additions. Unfortunately, the empeg starting acting abnormally at some point after this addition (memory errors/hick ups affecting playback... mostly minor stuff.. I have about 13,000 songs currently).

1st question, will more memory be the only thing I will need to install on the empeg to alleviate these problems?

2nd question, I have ordered a memory expansion board from Patrick (shipping date of the next batch still unkown?? maybe that's a 3rd question?) I have very limited soldering experience, and have never tried soldering small parts/computer boards.... Is there anyone that has found anyone willing to sell the service to do the install for them?

Any help or comments, or links to relevant posts that I couldn't track down would be appreciated.

Chris

Hmmm...

Having done this once or twice before ( ), let me give a few pointers...

Adding another disk and making a very large player can cause some issues - easily correctable. The most common types of things you can see are:

a) Very slow changes to read/write mode. The fix is to modify the rwm script to include the nocheck option.

b) The number of FIDs gets too high and syncs crash. The fix is to load Mark's set_empeg_max_fid version 7. This will allow syncs to work properly with insanely large numbers of FIDs.

c) fsck crashes. This is a memory issue. Enable swap before running fsck.

Now, you are mentioning that you get glitching with tracks. This is usually a disk read issue. Check that your jumper on the secondary drive is on tightly, that your IDE cable is in good condition. As a diagnostic step, turn on the hard drive status icon. Also, make sure that your reservecache value is set to a reasonable number (so there is enough memory to hold your database).

The thing is that I do not think the issues are strictly memory related. More memory is always nice and helpful, but the problems you are seeing should not happen, even with a base 16MB (assuming Mark2A).

True, but he did say he has ordered a memory board to come from the next batch, so he still may need install services if/when he gets the problems sorted out.

Very true. Good point.

The added memory certainly would not hurt, given the situation. Although you still do need to take precautions with the reservecache tag to avoid cache fill issues, depending on the software version you are on.

I completely agree! More memory is not a silver bullet. Hopefully the suggestions you had above take care of all of his problems.

thanks for your posts so far!

i have a markII, not a markIIa.
also, i have tried to up the reserveCache from default, and doing so completely locked my player... i set it to 64, based on some posts i read. as soon as it booted up, the empeg died trying to load databases, and it tried again, sending the unit into an endless loop. it was very difficult to get a command prompt back on the unit.

i am running version 2 final. I tried version 3 alpha 11, but the database would get 40% through updating, then fail.... no music would show up on the player at all, but i could play with settings. so i quickly gave up on alpha 11

the glitches i see are some VM: errors when shuffling large playlists, and audio cut outs in the first few seconds of a track.

here is an error that i receive quite frequently...

VM: do_try_to_free_pages failed for kswapd...

also, when the audio drops, i do believe the hard disk icon appears every time this happens. so to fix this, i gather that I should modify the rwm script. i will try this now

i live in california, and so eutronix seemes like the plan. i could get lighted button leds at the same time....

Okay.

If you are running a Mark2_, that implies 12MB of RAM. Also it may be worthwhile to see if that upgrade board will work with that model. I have to check, I do not remember off hand.

Given 12MB of RAM, memory issues are more likely, especially when initially setting up large drives. You should still not see this in playback, though. Do you have any other software (other than the player application and hijack) loaded that might take up memory?

The reservecache option tells the player how much memory to force the cache routine to leave for the player application and kernel. With this, you should try a larger number to fit larger database sizes. I would be surprised that you need to even include the line at all, but you should try larger numbers and work down.

When you see the disk icon, do you see it show up with a "W" indicator? That is a symptom that there is a wait for data on the disk. Typically I have seen this when the cache is trying to fill, starving the kernel for memory.

Try setting the reservecache to a higher number - 256 or 192 to start and work down. The goal is to save enough of the 12MB you have for the player, shrinking the cache size a bit. Your disks may remain spun up more, but the playback should be a bit better. The default, based on a somewhat dated version number (1.03) in the FAQ is 180.

As to the rwm, it is just convenience. I am sure that anytime you rwm your player to go into disk read/write mode, it must take forever. This way, it is almost immediate.

Ah... Okay. It does sound like the player is running out of memory for the database, but I had not known the values were that low...

Tony...are you out there? That post just begs for a FAQ update...

Hmm...upon looking, that info is in the Developer Info part of the site. Not sure who maintains that. It'd still be nice to have a FAQ entry so that people who don't know much about caching and emepgs can have some sample values to experiment with.

i was thinking the same thing regarding the FAQ. Besides just an update, perhaps even a separate entry for problems experienced with large databases. I would think these issues will be experienced more and more often.