[INTERNAL] `CurrentSession_OnPlaybackStateChanged` called twice for every play and pause for lot of media applications

[nopeless]

For some reason, Some media fires every playback event change twice for some events, and I am not sure why. I do think the codebase needs to be changed to accomodate this, however

Example: Open up a YouTube video in Chrome (other videos work too)

Read ouput

FluentFlyout Version

dev build, disabled resume media option

Windows Version

Windows 11 25H2, x64

List of behaviors (constantly updated)

• MusicBee: Play x1, Pause x1
• Chrome: Play x2, Pause x2
• Firefox, Firefox Webapp: Play x2-3, Pause x1-2
• Media Player (worst offender): Play x2~, Pause x2~ (sends new state on hovering the buttons???)

[nopeless]

this causes resume other media to completely break because I was assuming that this only fires once on pause/play

[nopeless]

I was always testing functionality with musicbee and I never noticed this issue until now, hence I never caught it. The codebase lacks a mechanism to detect when an "actual change" happens, and that is causing me issues

[unchihugo]

Hi @nopeless, sorry for the late reply! But the reason this happens we've discovered around the time we were implementing multi monitor support: sometimes media players (especially browsers) haven't completely loaded all data yet (often thumbnails), and they fire the API a second time to send the updated data, such as a missing thumbnail. Do you think a denounce for the auto play/pause would mitigate this issue?

[nopeless]

@unchihugo I think a proper way is to wrap media state an event emitter api and that way any consumer can subscribe to a state change for a specific property. a debounce might break other functionality is my guess

[unchihugo]

That would be a better permanent solution indeed, though much harder to execute. I've looked into refactoring and separating the existing media system to its own classes, but it's a big task since everything is really intertwined.