Issue #1: Skip Forward/Backwards causes crash
If you use `PlaybackProfile` to enable SKIP_FORWARD/SKIP_BACKWARD functionality, then the call to `onSong` will crash with an `UnexpectedTypeError`.
This happens consistently on a Fr645m using FW 4.0. I think the same thing happened on FW 3.70.
Issue #2 Incorrect `playbackPosition` on resume
Suppose you use `ActiveContent` to resume into some content at the 45 second position. The expectation is that `onSong` will receive a `SONG_EVENT_RESUME` call with `playbackPosition=45`. In practice what happens is that `playbackPosition=0`. If you're using `onSong` events to memorize the play position, then you'll end up saving off an incorrect value.
This happens consistently on the Fr645m.
Issue #3 Incorrect position shown in player
This might be related to #2. If you use `ActiveContent` to resume into a song, you would expect the player's timestamp to be correct; however, it shows '00:00' when resuming, even if the audio is actually much further along. The counter will then count up the relative positioning correctly, but be off by a constant factor. I *think* this worked on FW 3.70 for the Fr645m, but definitely doesn't for FW 4.0.
Issue #4 Incorrect `playbackPosition` on all events
This doesn't happen consistently, but when this happens, `playbackPosition` is always set to 0 no matter what the actual value should be. You can pause, unpause, start, stop, and no matter what, you always see playbackPosition as 0 even if the players timestamp counter advanced. Often when this happens, the audio drops out, so this might be a symptom of a lower level crash.
An example of this happening looks like:
[2018-10-11 16:35:30] {D} contentRefId=-2030043132 songEvent=0 playbackPosition=0
[2018-10-11 16:35:31] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:15:54] {D} contentRefId=-2030043132 songEvent=7 playbackPosition=0
[2018-10-11 18:16:14] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:16:16] {D} contentRefId=-2030043132 songEvent=7 playbackPosition=0
[2018-10-11 18:18:24] {D} contentRefId=-2030043132 songEvent=0 playbackPosition=0
[2018-10-11 18:18:31] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:18:34] {D} contentRefId=-2030043132 songEvent=7 playbackPosition=0
[2018-10-11 18:18:43] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:24:18] {D} contentRefId=-2030043132 songEvent=0 playbackPosition=0
[2018-10-11 18:24:32] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:24:38] {D} contentRefId=-2030043132 songEvent=7 playbackPosition=0
[2018-10-11 18:24:44] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:24:48] {D} contentRefId=-2030043132 songEvent=7 playbackPosition=0
[2018-10-11 18:25:08] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
[2018-10-11 18:30:39] {D} contentRefId=-2030043132 songEvent=0 playbackPosition=0
[2018-10-11 18:30:44] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=0
Whereas more 'correct' behavior looks like:
[2018-10-10 19:52:10] {D} contentRefId=-2030043134 songEvent=0 playbackPosition=0
[2018-10-10 20:01:57] {D} contentRefId=-2030043134 songEvent=4 playbackPosition=589
[2018-10-10 20:01:58] {D} contentRefId=-2030043133 songEvent=0 playbackPosition=0
[2018-10-10 20:22:52] {D} contentRefId=-2030043133 songEvent=4 playbackPosition=1254
[2018-10-10 20:22:53] {D} contentRefId=-2030043132 songEvent=0 playbackPosition=0
[2018-10-10 20:24:38] {D} contentRefId=-2030043132 songEvent=1 playbackPosition=106
[2018-10-10 20:24:39] {D} contentRefId=-2030043131 songEvent=0 playbackPosition=0
[2018-10-10 20:32:08] {D} contentRefId=-2030043131 songEvent=4 playbackPosition=451
[2018-10-10 20:32:08] {D} contentRefId=-2030043130 songEvent=0 playbackPosition=0
[2018-10-10 20:34:47] {D} contentRefId=-2030043132 songEvent=6 playbackPosition=159
