For some reason my main empeg has started acting up, and currently takes about 12 minutes to go through Building Databases and about the same again Loading Playlists. I have had it on v2.01final dev image for ages, and Hijack is at around 488.

Unfortunately I can't use emplode to fix it as it takes so long emplode gives up in disgust. Had a quick shot at fscking it (required both swapspaces enabled) but no joy.

Then went and tried the FAQ guidance



Unfortunately, even though most of the rm commands worked, the symptoms are exactly the same.

Now, I know what I should do - go for Mark's latest Bigdisk build and redo both disks, but that will involve getting an older machine out of the attic as this one has no serial port (the USB to serial works fine for hyperterm type stuff, but not for the .upgrade files)

Any thoughts before I take that route?

After using rm to nuke the database files, the next step is to do this:

rwm
player
# now wait for the player to rebuild databases and start up,
# then hit Control^C to kill it again, and do:
rom
exit

Problem solved.

He doesn't need the "rwm"; it's already been done. If it hadn't, all of the "rm"s would have failed. (Not that it hurts anything for it to be run again.)

The rest of it matches what he did, assuming what he did is what he pasted here. Yeah, it's a different route, but it gets you to exactly the same places.

The only thing I can imagine is that, in the place in my instructions where he types EXIT, it doesn't go back into the player software and therefore doesn't rebuild the databases.

At that point, Mark's instructions for running PLAYER would be more correct.

But from everything I understand, the instructions in the FAQ are correct and typing EXIT at that point should have done the right thing and caused the player software to rebuild the databases.

Question:

If Q <enter> doesn't work, and they end up pressing Ctrl-C to kill the player app, would EXIT get them back to the player at that point?

If not, perhaps that's what happened.

Should do, yes.

Using "exit" or at least "exec player" is better than just "player", as that last keeps the shell around in memory while the player runs, whereas "exec player" and "exit" both replace the shell with the player.

Peter

Thanks guys - things to try this afternoon. I have been ctrl-c ing, as 'q' isn't giving me access.

Hmm - okay have tried

rwm
player
# now wait for the player to rebuild databases and start up,
# then hit Control^C to kill it again, and do:
rom
exit

and tried

rwm
exec player
# Control^C took me to Shell Exit so I had to use another Control^C to kill it again, and do:
rom
exit

Both methods took about the same time - around 20 minutes at Building music databases and around 15 minutes at Loading playlists. And I get a time out on emplode if I try to connect (building databases doesn't complete by the time emplode gives up)

My next thing to try is timing on the Control^C - does it make a difference if I do it while the Loading Playlists message is up?

Also, interesting information point - if I wait the half hour until the player comes up selecting playlist from the front panel immediately gives me a segfault (maybe that is normal behaviour as I guess my playlists are nuked at that point)

Yes. You need to wait for each stage to finish before doing the next one. So at the shell prompt, type rwm, hit return, and don't do anything else until the next shell prompt "#" appears (this takes a while on big disks). Then exec the player, and don't do anything else until everything has finished building and the normal player screen appears. Then hit q, or Ctrl-C, and once the "#" appears issue the rom command.

Peter

Actually, on thinking about it a bit more, yes, it will do, sorry. It really is best to use "exit" and not "exec player" or "player".

Peter

Err.. missing step 0: kill off and close emplode/JEmplode *before* attempting any of this, and don't restart them until all of this has been completed.

And perhaps also do this after the database rebuild, before attempting to use emplode/jemplode:

rom
e2fsck -fy /
e2fsck -fy /dev/hda4
tune2fs -c -1 -i 0 /dev/hda4
tune2fs -c 1 -i 0 /dev/hda5

That should cure it permanently.

-ml

This is unusual. Have you been pressing the ENTER key after pressing q? And did you try it more than once?

I'm wondering if that's a symptom of some other kind of problem.

The software in question is 2.0?

About how many songs are on this player? Two disk drives or one?

Not in the light of the next question:

I don't think the player starts listening for q's until it's started up properly. Meanwhile Ctrl-C quits the player even if it's in the middle of the database rebuild we're trying to do in the first place.

Peter

Ah OK. Thanks.

I have not tried to do it during the Database message, but I have tried during the loading playlists message and waiting the full 35-40 minutes till the player starts...no difference in symptoms.
It doesn't do a faster rebuild when all the var/* files are removed, and although it does eventually get to the player I can't play anything, and emplode fails.


Don't worry - I have only tried them once the player is running again.

I'll try the tunefs stuff though - see if it changes anything.

I've never used q, as far as I can remember - it seemed to require faaster reflexes than I have



2 disks, around 22,000 tracks, version 2.01 final

Oh! Oh dear, now I look back upthread you did kind-of say that before, and I didn't notice. If that's the case, the problem you have isn't the one we've all been trying to fix for you. And it's one I haven't seen before against 2.01-final: I had thought we'd found and fixed all the "persistent database rebuild failure" problems, but your player must have come up with a new one. You probably have something bogus in your *0 files that the player thinks is some kind of mammoth playlist.

But as Empeg has now all ended and we don't have access to the source code any more, there's nothing I can have you do to diagnose this, I'm afraid. Under the unfortunate circumstances, the quickest way to get your player back to life, unless anyone's got any really bright ideas, is to delete the contents of both drives' "fids" directories and re-populate it from empty.

Peter

Oh, good point.

First, make sure this isn't simply a "second disk drive not appearing this film" problem.

If both drives are working fine and you can browse their FIDS folders... Something worth trying. Get a directory listing of all of the fids, divided into lists of the *1 files and *0 files. You might need to work with a largefile ASCII editor and/or a spreadsheet program to do this....

Ideally the *1 files should all be very tiny. If you find a huge one, that might be your culprit, examine its contents. The *0 files should be divided into two groups: All the MP3 files and all the playlist contents files. The MP3 files will be large and will be many in number (22,000), the playlist contents files will be relatively small and theoretically few in number. If possible grab all of the *0 playlists contents files and see if they all truly contain playlist content data, or if one of them is somehow corrupted.

Once scenario in which I can imagine this happening involves data from two different players. For example, trying to combine the FIDS folders of two disjoint players with multiple hard disks each. You could end up with a disjointed *1 and *0 file, and have the database expecting a playlist for the *0 file and getting an MP3 data file instead.

What about a situation where you have:
- Two disk drives
- One drive goes offline because of a loose cable
- You add some songs and synch
- Second drive comes back online
- You try to synch again

Might that cause a similar problem?

Thanks for all the help so far guys - I am trying to let this one last run through complete, then I'll check for a massive *1 file. Failing that I will go for the full rebuild with Mark's latest BigDisk - which I would have had to go for at some point anyway I'm sure.

And I have retrieved a machine with proper serial ports so I can give it a shot this weekend.

(I want to make sure it all works before Cambridge!!! :-)

One more somewhat obvious thing (to some of us) to try here:

Perhaps the player is running out of memory for that huge tracklist of yours.
So, do a swapon /dev/hda6 before re-attempting the recipe. This will give it more (virtual) memory to play with.

Cheers

Sorry - yep, I did try that this afternoon (as I noticed I needed /dev/hda6 and /dev/hdc6 to fsck fully)

Still no joy I'm afraid - tomorrow I'm running the bigdisk builder v10 and redoing the lot.

Well - there is definitely an issue somewhere. To get the builder to work I got rid of all the fids etc, then fsck'ed as it was complaining a lot but eventually that worked.

But then -

Running the bigdisk builder on each disk looks like it works but after installing either the v2.01 or the 3a11 on boot up I see a pump hda5 648:2 message come up briefly, and emplode sees 0 space

So I figure the easiest first step is just to buy a nice new shiny bigger disk (probably a 250) to replace the two currently there and run a build from new to see how it goes.

Then, if I can get that last wire fixed on for the memory upgrade that could help with things I guess.

And after that I have discovered after installing my new amp, wiring etc into the Forester that the dash DIN slots are not quite DIN. Specifically they are 5mm narrower than an empeg.

My Dremel awaits...

Yup, you are not the only person who has had to dremel their scooby dashboard. Plenty of examples in the install gallery on riocar.org. Some good solutions and nice installs in scoobies can be found there or by searching for subaru installs here on the BBS.