Open itsjustbrian opened 6 years ago
@arirawr I don't feel awesome about @mentioning people out of the blue but I filed this almost 2 months ago and it's a pretty substantial bug. Is the playback SDK still being maintained? Any update would be much appreciated.
Hi guys,
this seems to be still the case with the latest version. Is there any workaround this this? The player itself recognizes that it should start from the same old position again, so somehow it must get informed besides the player_state_changed event.
Kind regards
Issue found on September 2 2018.
Scope(s):
Chrome, Firefox
Steps to reproduce:
player_state_changed
events upon skipping (usually happens within 2 tries)Expected behaviour:
player_state_changed
should fire every timeActual behaviour:
player_state_changed
does not fireThe root cause is pretty easy to speculate on here. The behavior might have even been intentional, but would be a mistake IMO. In the above scenarios, the player state object that should have been fired by the event would be exactly the same as the last player state object received from
player_state_changed
. Taking step 4 from above as an example: the state you receive when first playing the song looks like{ currentTrack: foo, position: 0, paused: false }
, after waiting a few seconds and skipping to the beginning, the state would look exactly the same. I believe there's probably a check verifying some property of the player state has changed before firingplayer_state_changed
, but not firing the event in this scenario is compromising to app logic. Any interaction with external controls for a player should fire the event regardless.