Player locking up on first song

I've seen a couple of other posts to this nature, but they were all running older builds (that forumers said were flawed?), so those don't help me...

(I'm running the version2.0-beta11 software and Emplode).

My Empeg player now locks up after booting and starting the first song (in it's cache, I assume; it plays for 1-2 seconds then locks up). Before booting, it sits at the "Building Music Database..." screen for ~30 seconds before continuing to boot, much longer than normal.

What seems to have hosed the player is that I was running a sync overnight (via ethernet). When I checked on it the next morning both the player and Emplode software appeared to have hung at some point in the process (I was syncing about 1-2 gigs of music). I rebooted the player, and then started getting the problem.

I'm in no ways a unix adept, so any help is appreciated Thanks, I'm dreading driving into work without any music...

My Empeg player now locks up after booting and starting the first song (in it's cache, I assume; it plays for 1-2 seconds then locks up). Before booting, it sits at the "Building Music Database..." screen for ~30 seconds before continuing to boot, much longer than normal.

The first problem might be a corrupted MP3 file. Is it always the same song that locks you up?

The second problem can almost certainly be fixed by doing a re-synch. (Just open the player up with emplode, make a trivial change to a tag on one of your songs, and this will force a re-synch.)

tanstaafl.

It's always the same song, I'm assuming because it was the song that was playing before I initiated the sync.

I can't get into Emplode because the player is hard locking, which means Emplode can't access it. I get about 1 second where the player is actually past boot-up and Emplode begins to ping it before it hard locks all together and Emplode barfs.

-sigh-

I can't get into Emplode because the player is hard locking,

Don't be disheartened. This is easy to fix; unfortunately I am not smart enough to know how to do it. Something to do with making the player start on an empty playlist or something... it's in the FAQ but I couldn't even tell you where to look.

In a few hours all the people who are smarter than me will be back on the board and someone will have the answer.

It is not likely that your problem is serious.

tanstaafl.

Here is the FAQ entry on How do I stop it from trying to play a bad track?

Try this, i noticed your running beta 11, this is a bug which only effected beta 11. link

Topaz Monkey, make sure to do the following things which were already listed by others in this thread:

- Make the player start without a playlist.

- Make sure your config.ini file isn't hosed.

But because your player has the "building music databases" error, you'll also need to fix the corrupted database. And since you're a version behind, definitely make sure to upgrade to the latest version because it fixes some of the bugs that may have caused the problem in the first place.

So, I upgraded to beta13 but I'm still getting the problem.

Hooking up the player to a telnet program works, but I can't drop it to a shell prompt (I am running the dev image, fyi). It seems to just be ignoring my attempts to hit 'q' and starts the player anyway. There isn't a pause when this prompt displays that allows input, and mashing down on the 'q' key during boot-up didn't work, either.

HOWEVER, Ctrl+C on boot-up DOES work, and I was able to at least get the player to start without a playlist via your FAQ. I can navigate the player software now, but I still can't sync up with Emplode (the player and software freeze on "Checking Media/Checking disk integrity").

I've attached the log output from my telnet session during bootup, if any of you 3l33t h4x0rz want to try to decipher it. There are errors in there, but they're Greek to me...

If I could get to a shell prompt I'd try the other steps. Any thoughts?

but I still can't sync up with Emplode (the player and software freeze on "Checking Media/Checking disk integrity").

Then you probably need to do this, too.

Make sure that this hasn't all been caused by disk drive trouble, though. Doing an FSCK on a troublesome disk will only make things worse.

Greetings!

The bootlog looks normal, but there is something important.

It says that the maximum number of file system mounts was reached. This means that next sync, it will try to fsck the filesystem. This will take a long time. Your sync is not frozen, just doing a file system check. Let it finish.

Yeah, what Paul said. At first I discounted it because you said the player freezes, too. Now that I think about it, though, during a synch the player shouldn't be doing anything at all. So yeah, Paul's statement is right. The FAQ entry I linked is basically doing by-hand what the synch is trying to do.

You're the second person who thought the filesystem check was a freeze. Empeg guys, any chance of changing the "Checking File System" name to "Checking File System (may take a long time)"? Does that fit on the screen?

Maybe just "Get Coffee".

Paul is my new hero. It took about 15 minutes, but it worked.

I echo Tony's concern; the problem is that the sync art on the player freezes, and for all itents and purposes Emplode appears to be totally not responding, which is definitely confusing...

Since I'm here, OOC, is there a maximum recommended number of files to sync over Ethernet at any given time. I seem to remember running into Emplode actually freezing when syncing a lot of files to the player, but I didn't know if that was fixed in any revisions of the software. Any tips to avoid such troubles in the future is much appreciated

Thanks again guys!

Greetings!

It is mostly fixed. Most human sized syncs will go without any trouble at all. When I was rebuilding my player after cleaning all my mp3 files (VBR header trouble), I attempted a 100GB sync, just to try and break it. It did. I broke the sync into two or three smaller syncs, all worked perfectly. This was over USB.

So, as long as you are not doing anything really out there, you should be fine.

Note: I didn't even bother to report or post those massive sync attempts. That kind of event is so rare, that I didn't think it too interesting. If there is any desire to try and replicate that error for troubleshooting purposes, let me know.

Since I'm here, OOC, is there a maximum recommended number of files to sync over Ethernet at any given time.

No. If you're using the latest software, large synchs should be fine. The only thing you'd want to worry about is if the power goes out or Windows craps out on you mid-synch. For that reason, you'd want to do it in smaller batches so you don't have to re-do a bunch of work if something bad happens. But emplode/player should be good for big synchs at this point.

You mention hitting 'q', but are you hitting 'enter' after that?

Well, he's fixed the problem, so it's kind of moot now.

Is hitting Control-C an acceptable way of killing the player?

Is hitting Control-C an acceptable way of killing the player?

About as acceptable as using Ctrl-Alt-Del for closing a Windows application.

In other words, it's sometimes necessary when the regular method doesn't work, but don't do it unless you have to.

Actually, it is 100% perfectly acceptable and safe to use Control^C for this. What it does is tell the player that you want it to quit. If the player knows how to deal with this, it quits. If it doesn't know how to deal with it, then Linux forces it to terminate. Either way, all files get closed, and life goes on.

And since the Empeg's filesystems are R/O, there's no danger to the music data. The other hidden partitions may be getting updated at the time, but damage is extremely unlikely or even impossible here -- consider that it's all designed to lose power at any possible moment. Hitting Control^C for a more controlled shutdown is innocuous by comparism.

Cheers

Ah. I thought Ctrl-C would kill the player app with extreme prejudice, and (for instance) not give it a chance to write its current playlist position to flash. I stand corrected.

I don't know if the player actually "handles control^c" (no access to the source code here), but if it does, then it could do whatever cleanup it needs.

My understanding is that the playlist position is updated continuously (how often is that? see my earlier point), and gets commited to flash by the kernel on shutdown conditions.

Cheers

I sync'd an entire 50gb collection at one time.