Mark, I hope you got some sleep. I hope I get a chance to also.

Thanks again for all your help with everything. You've been awesome.



Now that I've got things working with the old BlueGiga dev board again I had a chance to retest V523. (Well I stayed up past 2am to get the assembly working again and I decided to stay up a little extra to test things too.)

Here's the current issues I'm seeing with V523:

- When the player is paused, the Z (source) and D (duration) data do not come out the serial port for the current track, they come out the serial port for the next track. Repro steps: Pause player. Press Next Track. Z and D do not come out at first. Press Next Track again. Z and D come out now, but they are not for that track, they are for the previous track. On the car stereo screen, the Album title is shown that is the album title from the previously-played track while all the other track metadata is for the current track.

- When the player wakes from sleep or the player has recovered from a low voltage event, this is a fresh reboot of the Arduino and the Bluetooth chip. This can also happen when you are listening to the stereo in Accessory mode and then you start your car, causing the voltage to drop briefly. When this happens, the deduplication feature does not allow the player application to repeat its track data to the serial port (usually it does repeat it in these situations). This results in "Unknown track on Empeg Car" on the car stereo screen quite frequently. This did not occur with V522, there was always the correct track on the screen after any sorts of power events on the empeg player. Repro steps: With the player connected and playing, sleep and then wake the player from its front panel. The bluetooth will disconnect and reconnect, and when it reconnects, it will say "Unknown track on Empeg Car".

- The deduplication feature prevents me from being able to key off of any single particular piece of serial port data or even any particular sequence of serial port data (since, when paused, there are no time sequence ("#") lines coming out) to decide when I have a full track data set and can flag the host stereo that new data is available. This results in my code having to flag the host stereo for every line of new track data. For each new track this can be up to 5-7 repeated "TRACK_CHANGED" notifications instead of just one. For a single track change, or maybe two or three, this is OK, but pressing "next-next-next-next-next" on the player front panel in quick succession is enough to overload the host stereo and make it stop getting new track data altogether. This is only necessary in V523; in V522 with single notifications then the host stereo eventually caught up and multiple track changes didn't seem to confuse it.

I think the last two mean that we should go back to non-deduplicated (but keeping all your other improvements) and I'll fix the full-player-shuffle issue in a different way in the code. I think that trying to fix those last two issues would be just too complicated for Hijack and out of its scope. What do you think?

Thanks again!