Play nicely with multiple mpv instances

[NickHu]

I don't know exactly what the correct behaviour in general for this ought to be, but I observed the following behaviour that I would consider to be a bug:

• Pause music I was listening to in mpv
• Start watching a video with another instance of mpv
  • MPRIS now emits the track information from the video (good)
• Video runs until the end

Now, I can resume the music with MPRIS (good), but the track information emitted is that of the video I watched instead of the music.

[hoyon]

I was wondering when this would come up. Currently, the first instance of mpv will create a bus named mpv and any subsequent mpv instances will create separate buses called mpv.instance<PID> as stated in the spec, and will operate independently. This should be no different than if you had for example mpv and vlc running at the same time. The issue is: which bus should the MPRIS consumer listen to?

What are you using to consume the MPRIS data? It's possible that when the video starts, control is handed over to the video MPRIS bus and the new metadata is retrieved since a metadata changed signal will be emitted. But when the video ends and it returns to using the original music instance, it is waiting for the metadata changed signal, which the original instance can't know it has to give, instead of getting the metadata info on its own.

What happens if after following the steps above, you subsequently change tracks, triggering the metadata changed signal?

[NickHu]

Yes, essentially this is what I think is happening. After the track changes, the metadata correctly reflects the new track.

[hoyon]

Maybe a possible workaround to this would be to emit the metadata changed signal whenever playback is resumed and maybe on other events, but this is quite a specific situation which would be better fixed by the client application. Conversely, adding this probably wouldn't do any harm.

I'll have a play around with this later in the week when I have time.