Mk2a, 2.0b7, Hijack v89.

I was listening today and I switched tracks whilst in Transient info mode. As the info line was scrolling downwards to "hide," it stopped suddenly. The song kept playing but all input and display was frozen. This is similar to lockups I've seen elsewhere but under different circumstances (I wasn't changing playlists, for instance.)

I guess it'd be nice if the Empeg team could tell us if there are just general instability problems with this build, or if these are all separate bugs in different areas of the code. Or maybe it's my Empeg slowly dying or something... I don't know how I'd reproduce it, it just seems sporadic at this point.

Other lockups I've seen were followed by a quick restart of the player app, no such animal this time.

This particular bug is already in the internal bug list.

At least I remember it being there. I'm searching and having trouble finding it, there's so many bugs on the bug list now.

If anyone else on the alpha team can locate the bug in the internal bug list, it's the one that links back to this BBS with the screen shot of the transient line freeze. I just want to check and make sure that the bug is still marked as "open".

Still present in 2.0b11

Same symptoms as before.

Tom

Yes, this was being discussed on the alpha team list for betas 10 and 11, we are aware that it still happens occasionally. Too bad, because it's a real show-stopper.

I haven't had it happen since beta9, but maybe I'm just lucky.

And I still can't locate the existing bug number in the internal database.

You're just lucky. Because I had it happen within the first hour of having updated.

Bruno

Awww crap. I haven't had opportunities to test my Empeg much this weekend so I was hoping this bug was nailed... Is there any way they can release some kind of instrumented build of the software so we can try to get this one?

I see this quite often. The interesting thing is that if you are patient it will recover by itself. Is this a clue?

Beta 11 and all recent versions of Hijack in a Mk2A

Lynn

I've been getting this almost once a day while in the car. It never seems to happen on AC power. The interface just locks up but it keeps on a'playin. Happened again today. Then another weird one... it locked up, and i hit the top button to see if it would power down, but instead it paused. I hit it again to see if it would unpause, and the counter indicated it was playing, but no sound was coming out. It would skip to the next track, and you could hear a blip of the song, then it would go silent again, though the counter was still going. I pulled it out and pushed the player back in to reboot, and all was well. b11 on a Mk2 by the way

I've been getting this almost once a day while in the car. It never seems to happen on AC power.

I get it on AC power.

And I suspect that it happens a lot more often than most people realize. If you just leave the player alone (in my case, it takes 18 minutes) the problem cures itself, and I wonder how many times it happens like that and nobody notices?

tanstaafl.

ahhh... very good point. In other words, during my 45 minute commute to work when i just slap it on shuffle and don't touch it, it could lock up a few times and keep playing and i wouldn't notice. Interestin'.

Have we eliminated Hijack as a cause of this yet??

Have we eliminated Hijack as a cause of this yet?

Correct. Doug doesn't run Hijack.

FWIW, I'll throw in my data point here.

I ran as-delivered 1.02 consumer image on my new 60GB Mk2a for quite a while. No funny behavior.

I changed to 2.0b11developer + Hijack 2.96 the day beta 11 was released. I have tended to leave it running 24x7 on AC power playing a shuffle of my top-level playlist to see how things go..

I did get some fail-to-reboot-after-synch errors previously reported here, but it always came back. I've left the clock visual running in case of lock-ups. It locked last night while I was asleep and only unlocked when I power-cycled it ~6 hours later.

Doug is your non-Hijack control subject, I see. if you need another I'd be willing to back Hijack out (I haven't really exercised it yet, anyway).

(Odd, probably unrelated oddity: Emplode was finding my player just fine with broadcasts, but it won't now unless I change to the specific player address)

I havn't seen this bug since I upgraded to 2.0b11, but I did get lock ups several times with 2.07b, but I'm not sure if it is the same thing. I can tell you that every time this happened after I restored a bookmark, powered the player off, and back on. Maybe this was a different bug that was fixed in 2.0b11, but I couldn't find anything about it.

-Jeff

Lockups occur both on my my MK2a and my MK2, in 1.03, beta7 and beta11... especially in radio mode. Today for the first time while playing a MP3... [sigh] My toy is ill....

A couple more bits of data...

I think these UI lockups happen more frequently than people realize, since they are "self-repairing". I made a five hour road trip yesterday, and there were four UI lockups that I noticed and no idea how many others went un-noticed.

Interestingly enough, my last lockup was in progress when I reached my destination, and that was when I got a repeat of a puzzling problem I had experienced before: when I turned off the ignition, the player stayed on, but I think the amplifiers were off because instead of music all I got was a quiet low-pitched buzzing sound. Pulling the player from the sled to force a re-boot fixed it.

tanstaafl.

I've also experienced the same lockups with b7 & b11. I too have turned the ignition off whilst a lockup is in progress and the player remains on and the amps also remain on. First time this happened was filling up with petrol so didn't reboot, left music playing for passengers, when the ignition was turned back on the player switched into standby, and had to be pulled to reboot. The lockups allways occur with the hard disc spin up icon activated but without the central disc read portion lit.

Mark.

Yes, this is the known behavior of the lockups. It ignores all inputs while it is locked.

"Inputs" in this case is defined as:

- Front panel controls
- IR commands
- Stalk commands
- serial commands
- commands from other connectors including ign.sense, tel.mute, etc.

I noticed something else last night during a lock up while I was driving. The player was in "transient" mode and locked up input with abount one pixel of info still visible at the bottom of the screen. As we have all noticed, the visuals kept playing but the player accepted no new input. The thing I noted was that when the player switched to the next track, no transient information was displayed and the one pixel row of information still stayed the same (of course unreadable, but I could tell these pixels wern't changing). This may be nothing, but it would seem to me to indicate a hang or a deadlock in the transient code (or probably not since I'm sure we would have all noticed if this only happend in transient mode). Oh well, just one more observation

-Jeff

my lockups often happen at exactly this point, when the transient info has almost disappeared. if i let it go several minutes, sometimes the music will halt and the player locks up completely.

--dan.

Yeah, it is pretty well known that there's a possible tie-in with transient info mode, but people have seen lockups in other situations as well... Transient seems to contriubte to it though.

In reply to:

---

I noticed something else last night during a lock up while I was driving. The player was in "transient" mode and locked up input with abount one pixel of info still visible at the bottom of the screen. As we have all noticed, the visuals kept playing but the player accepted no new input. The thing I noted was that when the player switched to the next track, no transient information was displayed and the one pixel row of information still stayed the same (of course unreadable, but I could tell these pixels wern't changing). This may be nothing, but it would seem to me to indicate a hang or a deadlock in the transient code (or probably not since I'm sure we would have all noticed if this only happend in transient mode). Oh well, just one more observation

---

See the thread here about the "1 pixel " thing.

Yeah, the more I think about this one, the more I'm convinced that it can only be due to the Linux jiffies (scheduler) counter not incrementing (or incrementing very slowly). Of course, this is impossible, but it does seem to be happening anyway.

Clues:

display continues to update

IR input is queued, but not processed

a Hijack 1-second popup has been observed to remain on the screen, while visuals dancing about behind it.. this one is the kicker, since that popup WILL disappear if jiffies are running, and will NOT disappear otherwise. The fact that the visuals are dancing shows that Hijack is running (it controls ALL screen updates).

lockup disappears after a while, and queued IR presses are then processed.

So v221 of Hijack now has code to detect this, and to popup an error message for an extended period whenever it happens (any button press after the lockup ends will clear the message).

So, please report to me if you ever see such a message.

Thanks

Hey, I haven't been on the board for a long while, and I wanted to say that I used to have the mysterious lockup at least once a day, but haven't had it ONCE for about 4 months!

Mark Lord? Did you fix something in HiJack afterall? I'm on 254.

I still use transient mode regularly.

One thing I did do that might matter is I replaced logo.raw back in February (per SE_Sport_Driver's excellent advice here)

A coincidence? Hmmm.

Mark Lord? Did you fix something in HiJack afterall?

Yes, he did. The more recent versions of the Hijack kernel fix the "stuck jiffies" bug that was causing those freak lockups in the 2.0 betas.

The current-release 2.0 Beta 11 still has the bug in its stock kernel, adding a recent Hijack to 2.0 Beta 11 fixes the lockups.

The next public beta release will have Mark's fix built-in to the stock player software so that you don't need to install hijack to fix the lockup.