Mac media keys don't work if another app takes lock

[addiittya2006]

mpv version and platform

mpv v0.26.0 macOS 10.12.5

Reproduction steps

1. Open mpv with multiple files
2. Open another app like Spotify

Expected behavior

Even when the active window is mpv the media keys are locked with Spotify and change tracks instead of shuffling files

Actual behavior

It should progress the videos which works when spotify is not open.

[Akemi]

247d46d that should fix it. feel free to test it.

[lsnch]

Same problem the other way round. If I switch back to Spotify and press play, mpv now intercepts that event. v0.26.0 had the lowest priority, so now v0.27.0 has the highest? Shouldn't the top priority app be the one which was focused last?

[Akemi]

then Spotify has to be fixed. i bet if you first start Spotify, then mpv 0.26 and switch the focus back to Spotify, it doesn't work either for Spotify and the 'priority' was still on mpv.

the API we use, and Spotify probably uses too, only allows to add an event tap at the top or the bottom of the global event list, but not in-between. so what happened with mpv 0.26 is that when you started it first it added itself at the top. after that when you opened Spotify, Spotify added itself at the top which left mpv as second. when refocusing mpv it was still at the second spot and Spotify got the media key events. what i did is that mpv now re-adds itself to the top of the global event list when being focused, so it gets the media key events again. since Spotify doesn't get the priority after refocusing again, i would guess it doesn't do the same, which it should do.

Shouldn't the top priority app be the one which was focused last?

not every App, only those who actually want the requested keys. that's also the reason why we can't remove mpv from the global event list when it's not focused, since it still wants to get those keys if no other App actually requested those keys.

the only solution is probably using a newer API, if there is one. if i had to guess it's probably MPRemoteCommandCenter what we need, which is a 10.12.1+ feature.

[lsnch]

I did some testing with VLC, iTunes, mpv 0.26.0_1 and 0.27.0...
I'll list apps in order of launch. Several lines means they produce the same result.
0.26 = mpv 0.26.0_1
0.27 = mpv 0.27.0

• VLC, iTunes
• iTunes, VLC

play/pause affects only the last focused app. Since both of them are working properly here, one would assume the problem is not in those two.

• iTunes, 0.26
• iTunes, 0.27
• 0.26, iTunes
• 0.27, iTunes

mpv always intercepts play/pause event, no matter where the focus is.

• 0.26, VLC
• VLC, 0.26

VLC always intercepts, no matter where the focus is.

• 0.27, VLC

since VLC was opened last, it has focus, and it does intercept event, mpv is quiet. If focus moves to mpv once, from this point forward both of them receive event no matter where the focus is.

• VLC, 0.27

both receive event no matter where the focus is.

MacOS 10.11.6, VLC 2.2.6, iTunes 12.7.166, mpvs were brewed with bundles. Apps were windowed on one osx desktop/space (no fullscreen). One audio file was used.

edit: tested spotify

• 0.26, spotify

spotify always intercepts

• spotify, 0.26
• spotify, 0.27

mpv always intercepts

• 0.27, spotify

same thing as 0.27, VLC. Spotify intercepts, if mpv gets focus once it won't let go :) (no matter where the focus will be)

• spotify, itunes, vlc in any order

last app focused gets the event.

• vlc, itunes, spotify, 0.26
• vlc, itunes, spotify, 0.27

feels like there's some sort of flag... If an app gets focus, and it is an app that can receive media events (spotify, itunes) it sets this flag to itself.
For example, focus goes like this:

1. vlc
2. mpv
3. finder
4. chrome
5. itunes

1-4: event goes to both vlc and mpv
5. event goes to mpv only

I feel like mpv does not consider itself a proper media player, it doesn't want to be bothered with flags. vlc doesn't consider mpv a player either. itunes and spotify can't reach those events because mpv blocks them off. If mpv gets focus once it will listen to those events until it is killed. if there's no mpv, once vlc sees another media player it lets go of media events 'control' and gives away to the next guy. mpv is like a cocky bully. vlc is like a big strong guy and yet still respects small media apps who cant stand up to bullies, while ignoring bullies. Hope that makes sense.

[addiittya2006]

Yes, also when Boom 3D is used the audio channel from mpv is totally muted and is not considered media. This issue need to be reopened, we'll search for fixes.

[Akemi]

first of all, your assumption that there is no problem with VLC is wrong. VLC uses an 'external' dependency that handles the global events. this small lib uses some kind of 'whitelist' to identify Apps that use media keys. mpv is not part of that list, and VLC doesn't consider mpv a 'media player' (so i would say VLC is being a bully here by ignoring mpv). that is one part of the problem and why mpv and VLC can both get the media key events. this needs to be 'fixed' in that library and can't be fixed within mpv. imo this is just a very fickle way to solve a problem that should be solved by Apple itself with an appropriate API and not with a workaround that isn't working in all cases. tbh what mpv does now is way less fickle and if the other Apps would just do the same there wouldn't be a problem and there wouldn't be a need for a whitelist. that lib also keeps track of the most recent focused App, that is on that whitelist. logic that shouldn't be part of every App but of the API itself.

the other problem is, that mpv doesn't use that library and hence is not compatible with the way VLC and other Apps handle this feature.

so the difference is that, mpv sets itself to the highest priority when being refocused, the other Apps don't. they instead leave themselves at their current place (priority) in the event list but keep track of the most recently focused App (that is on that whitelist) and stop interpreting the requested key events and propagate them down the event list if they are not the most recently focused App themselves.

this mess is completely Apple's fault for not providing a proper API in the first place.

Yes, also when Boom 3D is used the audio channel from mpv is totally muted and is not considered media.

how is that related to this issue?

This issue need to be reopened, we'll search for fixes.

nope i don't see it that way.

[lsnch]

this is just a very fickle way to solve a problem that should be solved by Apple itself

I agree, but there are lots of old versions of MacOS still in use for different reasons that won't have that updated API (all before 10.12.1 which introduces, like you said, MPRemoteCommandCenter, if I understand this right)

this needs to be 'fixed' in that library

one line fix to the lib and subsequent update to the apps using that lib seems far more likely than apple rolling out some sort of update for older systems

mpv doesn't use that library

would that be hard to implement?

what mpv does now is way less fickle and if the other Apps would just do the same

I see this happening with 3rd party apps, but apple will never go for that. Any app which uses current mpv's way will block apple's apps.

[Akemi]

I agree, but there are lots of old versions of MacOS still in use for different reasons that won't have that updated API (all before 10.12.1 which introduces, like you said, MPRemoteCommandCenter, if I understand this right)

that can't be helped and that is how Apple and software works. it's Apple's fault for ignoring this problem at least since 2011. i also can't even say if the new API works as one would expect since i didn't test it yet.

one line fix to the lib and subsequent update to the apps using that lib seems far more likely than apple rolling out some sort of update for older systems

i would agree in theory, but in practice VLC didn't update their lib since the end of 2014, even though the main rep of the lib was updated the last at the end of of 2015. it also is not just a one line fix, see below.

would that be hard to implement?

nope not at all. a problem could be the license though, but if BSD3 license is correct it should be permissive enough. the bigger problem is that this lib depends on the bundle identifier, which mpv doesn't have when used from the terminal. it will (most likely completely) break the media key usage when mpv is used from the terminal.

I see this happening with 3rd party apps, but apple will never go for that. Any app which uses current mpv's way will block apple's apps.

in that case i would say 'screw' Apple Apps.

i am not in favour of supporting a lib that was created around bad assumptions and not working 100% correctly. it should first be fixed, since there are definitely better ways.