guihkx
commented
3 years ago I dug a little into this extension's code and came across these two methods:
If I understand correctly, they're used to determine if a player has a valid interface for volume/shuffle/loop controls.
When called, they will first store the current value of the property, then change it to something else, then restore its initial value. By doing so, this extension is able to determine exactly what controls the current player supports, and will add it (or hide it) on its GNOME Shell widget. For example, if I were to delete this line that calls _testVolume():
Then the volume slider would not be shown in the widget.
So, back to the main issue: For some reason that I'm not aware of, while in the process of switching/toggling values for these properties, either this extension or mpd-mpris will sometimes get confused and do not update these values in the proper order.
Example:
- Extension asks mpd-mpris for the current volume state
- mpd-mpris replies with 0.5 (example)
- Extension stores that value
- Extension asks mpd-mpris to set the volume to 0.0
- Extension asks mpd-mpris to set the volume back to 0.5
I don't know who's at fault here, but sometimes mpd-mpris will set the volume to 0.5 first, then only later set the volume to 0.0.
A temporary, ugly hack I found for now, is to merely update these properties with their own current values, instead of replacing the initial value with something else, then restoring that initial value later. The patch:
Click here to expand
```diff diff --git a/mprisindicatorbutton@JasonLG1979.github.io/dbus.js b/mprisindicatorbutton@JasonLG1979.github.io/dbus.js index e8a66f9..581fc69 100644 --- a/mprisindicatorbutton@JasonLG1979.github.io/dbus.js +++ b/mprisindicatorbutton@JasonLG1979.github.io/dbus.js @@ -1816,14 +1816,10 @@ const MprisProxyHandler = GObject.registerClass({ } else { if (this._playerProxy.Shuffle !== null) { let initialShuffle = this._playerProxy.Shuffle || false; - this._playerProxy.Shuffle = !initialShuffle; this._playerProxy.Shuffle = initialShuffle; } if (this._playerProxy.LoopStatus !== null) { let initialLoopStatus = this._playerProxy.LoopStatus || 'None'; - this._playerProxy.LoopStatus = initialLoopStatus === 'None' ? 'Playlist' - : initialLoopStatus === 'Playlist' ? 'Track' - : 'None'; this._playerProxy.LoopStatus = initialLoopStatus; } } @@ -1883,11 +1879,6 @@ const MprisProxyHandler = GObject.registerClass({ // remains hidden since it's pointless to show a widget that doesn't do anything... if (this._playerProxy.Volume) { let initialVolume = this._playerProxy.Volume || 0.0; - this._playerProxy.Volume = initialVolume <= 0.0 - ? 0.1 - : initialVolume >= 1.0 - ? 0.9 - : Math.min(initialVolume - 0.1, 0.0); this._playerProxy.Volume = initialVolume; } } ```Obviously, I haven't tested with other players beside MPD / mpd-mpris, so it's likely that it will break something. But hey, works for me™ and I'm happy for now. :)
JasonLG1979
v4rakh
Describe the bug
I'm using this service/daemon called mpd-mpris, which implements the MPRIS protocol for the Music Player Daemon (MPD).
It works almost perfectly with this extension. There are two issues I'm experiencing right now:
mpd-mprisdaemon, some playback flags are randomly enabled/disabled in MPD (for example: shuffle mode, random mode, single mode).Initially, I thought this was an issue with the
mpd-mprisdaemon (and I reported it to their developer), but if I actually disable this extension, I'm unable to reproduce these two bugs!Since it's not clear if this is a bug with
mpd-mprisor this extension, @natsukagami (the creator ofmpd-mpris) suggested me to report it here, and it's also willing to help on a possible fix.Steps To Reproduce:
Note: This needs both MPD and mpd-mpris set up.
The first issue can be reproduced by either:
mpd-mprisdaemon: Some playblack flags will be randomly enabled/disabled. Here's a video I recorded showing this behavior.mpd-mprisservice (and make sure to not have any playback flags enabled in MPD. You can use ncmpcpp to check which flags are enabled); Then re-enable this extension. Playblack flags will be randomly set/unset each time you do this.The second issue:
mpd-mprislike normalExpected behavior
System Details (please complete the following information):