This has been documented before, but I thought we could start a new thread on it so we could get to the bottom of the issue.

Here are the steps to reproduce the bug (assuming working Hijack/GPSapp/GPS receiver):

- Boot the player.
- Listen to a piece of music at a moderate volume level.
- Enter Hijack.
- Enter GPSapp.
- On mine it comes up to the satellite screen. Wait for it to show locked satellites.
- Select a route.
- Hold down the bottom button to switch to the map display.
- Use the left and right front-panel buttons to zoom in and out of the map. Note that they work.
- Press the top button to exit GPSapp, then again to exit hijack.
- Enter Hijack.
- Enter GPSapp.
- GPSapp is still running so it's still on the map screen with the route already loaded.
- Press the right front-panel button.
- Instead of zooming the map, it begins fast-forwarding the song.

I can do the above steps pretty consistently. It always behaves properly the first time into GPSapp, and almost always fails the second time I enter GPSapp (as listed above).

What the fast-forward tells me is that the buttonDOWN event for the front-panel button got "lost" by either hijack or GPSapp, and instead passed through to the player app. The following event, the buttonUP event, did not pass through to the player app, but it didn't do anything useful/visible for GPSapp either (if it even got trapped by GPSapp/hijack at all).

So what we need to find out is...

- What's happening?
- Is it in the GPSapp code or the Hijack code?
- Who's gonna fix it?

I'd be willing to test any debug builds of either GPSapp or Hijack that anyone wants to throw my direction.

ioctl gets something. either we can use it or we free it. if we can use it, we do.

do we need to copy it if we known we can't use it?

The message I replied to got eaten. WTF?

Sorry - I realised my mis-interpretation and deleted the post, not realising that anyone had read it that fast! (Somehow my eyes had missed the 'return' in that conditional.)

Has it been verified to be a gpsapp bug?

Sorry, couldn't resist.

Yeah, well, you removing your post somehow orphaned my reply, which is in the "last 24 hours" summary but not referenced in the thread.

What I 'think' that could be going on here, is that when we restart (or possibly a better term 'reenter') GPSapp, Hijack refreshes the screen, but the application itself doesn't know it is back yet. Some of it's code might even be swapped out and we're waiting for the disk to spin up.

We're blocked in HIJACK_WAITMENU, and once gpsapp is woken up the first thing it does is HIJACK_BINDBUTTONS, and then HIJACK_SETGEOM. When we start up the first time, the screen isn't redirected until we set the geometry. But if this is the second time around, you might be looking at a stale image and your button presses really are going to the player because technically gpsapp isn't in control yet.

This is just a theory, I would have to dig into the hijack code to see if this is even remotely possible. I could add a special 'Waiting' screen right before we give up control. That way if my theory is correct you should be seeing that when gpsapp is reentered before it takes control.

But if this is the second time around, you might be looking at a stale image and your button presses really are going to the player because technically gpsapp isn't in control yet.

Interesting theory, but my recollection is that GPSapp is still working fine, the map screen is updating, etc.... But I could be remembering that wrong.

In my experience, this was pretty easy to reproduce consistently using the steps I outlined, so theoretically anyone with GPSapp should be able to reproduce it?

I could add a special 'Waiting' screen right before we give up control. That way if my theory is correct you should be seeing that when gpsapp is reentered before it takes control.

I'd be happy to test that build if you wanted to throw it my way.

Interesting note: I can't seem to reproduce the problem in "force DC/Car" mode without the GPS actually attached (and keying past the "waiting for data from the GPS receiver" screen). I think I have to actually have the GPS unit connected and sending data for the bug to happen. Perhaps it's got something to do with the serial communication code?

Edit: Changed "thread" to "code". Nyah Nyah.

GPSapp isn't threaded.

But if this is the second time around, you might be looking at a stale image and your button presses really are going to the player because technically gpsapp isn't in control yet.

I checked this out today while I was out to lunch. The behavior was as follows:

First time entering GPSapp, worked fine.

Second time entering GPSapp, the map screen was updating, my speed was changing on the screen, everything seemed to be working correctly. It was not a stale image, it was tracking my correct location on the route. When I pressed the right button to zoom the map, it fast-forwarded the music instead.

So it's not a stale image, and GPSapp is working when the bug occurs.

Could be a similar problem:

When I start the car, empeg starts, I start gpsapp and everything works fine, the route is displayed.

When turning ignition off (e.g. during tanking or a brake) and on again when empeg has not powered down yet empeg comes back with mp3-screens but not with gpsapp. Holding the knob pressed brings up gpsapp but not hijack menu.

Sometimes gpsapp hangs up the empeg completely during this process.

Juergen

This is probably related to a similar bug that happens with all third-party apps (not just GPSapp, I've seen it happen with Empacman, for example) where exiting the app and entering the Hijack menu again causes the behavior you describe. You don't have to turn off the ignition to reproduce the bug, you can reproduce it by going in and out of the app enough times.

As a temporary work-around in your case, you might want to consider making your standby timeout shorter. I've found that changing the timeout to 5 seconds or less tends to work around certain bugs that happen, like the one you described.

Holding the knob pressed brings up gpsapp but not hijack menu.

By the way, in that case, what you're seeing is (I believe) a "stale screen" as Jan described earlier. It's a frame buffer of the screen when GPSapp was running, but it's just a "screen shot", it's not GPSapp actually running.

This also seems to be somehow related to the bug where apps disappear from the GPSapp menu after they're bound to it.

I tried, and tried, and tried again. But haven't been able to get this behaviour at all. Yes, I was in the car and not using hijack's 'DC mode' override.

But from your description, this should not be possible. I've looked at my code, and it clearly does 'BINDBUTTONS', followed by 'SETGEOM', before flushing pending serial input and refresing the screen. The advantage of a single thread application, I know that gpsapp doesn't refresh the screen until the hijack redirections are all registered.

The only thing I can think of now is that hijack somehow clobbered the array that I passed along with the ioctl. I don't see any code in hijack that would in fact do so. But it isn't too much trouble to pass a copy of the array instead of the original.

I have noticed the 'standby' bug. When I start my engine, the accessory line is temporarily turned off and the empeg blinks into standby for a moment. When it returns, it always returns to the player. My guess is that the player in fact exits and restarts and that hijack responds to the player startup by reinitializing some pointer and completely forgets that there was a 3rd party app running.

Because the app isn't getting any input, it simply runs indefinitely in the background and can't tell anything is wrong because the waitbuttons, pollbuttons and screen refresh ioctls never fail. Hmm, that is probably the easiest solution, add an error code to some of these ioctls when hijack doesn't think that the app is 'in control'.

Yes, that describes the bug well, so your probably right.

Reducing the time-out is not an option for me as my WLAN is only powered when ignition is off and empeg still on. So when I reduce the time-out WLAN will no longer work.

Juergen

But it isn't too much trouble to pass a copy of the array instead of the original.

I'd be happy to test a copy of a binary which tried this functionality.

Another thing to consider... I'm probably running a different model of GPS than you are, and I can't reproduce the bug when there's no serial communication going on, so perhaps there's something about the serial communications that are going wonky and causing this?

Here's another couple of things that makes me think of serial:

- Sometimes, when I start GPSapp, the music hiccups as GPSapp starts up.

- Sometimes, GPSapp displays a blank black screen for a long time (even as long as 20 seconds on occasion) before the first "Waiting for data from GPS receiver" message appears.

The "Waiting for data" message never does more than a brief blink, so once the receiver is connected then the communication happens fine. But there's that long black pause before the first message is even listened for that makes me worry that the app is having trouble talking to the GPS on the serial port at first. Any idea whether that might be related?

- Sometimes, when I start GPSapp, the music hiccups as GPSapp starts up.

I have that routinely.

Bump.

Who else sees this problem and can reproduce it in GPSapp?

Another bump.

I wasn't able to reproduce the problem today. There are three things that are different about my player's configuration now, and I wonder which one of these things could be responsible?

- Slightly newer Hijack version.

- New map data loaded, using Siberia's method instead of MapsOnUs.

- [ir_translate] section added to config.ini to take advantage of the new .V feature.

I wonder if any of those things are the reason? Of the three, I'd say the latter is the most likely candidate.

There's pretty much no way the map data could matter.