Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors with gpmdp ( google-play-music-desktop-player ) #35

Closed
kingy9000 opened this issue Sep 12, 2016 · 9 comments
Closed

Errors with gpmdp ( google-play-music-desktop-player ) #35

kingy9000 opened this issue Sep 12, 2016 · 9 comments

Comments

@kingy9000
Copy link

kingy9000 commented Sep 12, 2016

Playerctl always outputs the following when I control google-play-music-desktop-player, as identified by playerctl -l. I'll refer to it as gpmdp from now.

(playerctl:13598): GLib-GIO-WARNING **: Received property Rate with type y does not match expected type d in the expected interface

(playerctl:13598): GLib-GIO-WARNING **: Received property Volume with type y does not match expected type d in the expected interface

(playerctl:13598): GLib-GIO-WARNING **: Received property Position with type u does not match expected type x in the expected interface

(playerctl:13598): GLib-GIO-WARNING **: Received property MinimumRate with type y does not match expected type d in the expected interface

(playerctl:13598): GLib-GIO-WARNING **: Received property MaximumRate with type y does not match expected type d in the expected interface

Playerctl is able to control gpmdp successfully but will cause the shell to get stuck after doing so and prevent a program that's supposed to run afterwards from running.

For example, I run a command to update my status bar with the current playing song.

Thanks for reading and let me know if any extra info is needed.

EDIT: I am running playerctl v0.5.0 and gpdmp v3.6.0. There are no new commits to the repo since v0.5.0 came out so I assume there are no differences between the release and the git version.

@ChrisB9
Copy link

ChrisB9 commented Oct 2, 2016

I am getting the same warning, though it only stucks by the commands pause, play-pause and stop
but its printing this by each mpris-command

` (playerctl:10910): GLib-GIO-WARNING **: Received property Rate with type y does not match expected type d in the expected interface

(playerctl:10910): GLib-GIO-WARNING **: Received property Volume with type y does not match expected type d in the expected interface

(playerctl:10910): GLib-GIO-WARNING **: Received property Position with type u does not match expected type x in the expected interface

(playerctl:10910): GLib-GIO-WARNING **: Received property MinimumRate with type y does not match expected type d in the expected interface

(playerctl:10910): GLib-GIO-WARNING **: Received property MaximumRate with type y does not match expected type d in the expected interface `

@acrisci acrisci self-assigned this Oct 23, 2016
@hatzel
Copy link

hatzel commented Nov 17, 2016

Any news on this? I would be willing to devote some time to figuring this out and fixing it.

@acrisci
Copy link
Member

acrisci commented Nov 17, 2016

@hatzel go ahead. If you have questions, please don't hesitate to ask.

@acrisci acrisci removed their assignment Nov 17, 2016
@hatzel
Copy link

hatzel commented Nov 27, 2016

Okay, sorry for taking so long. It appears that this is not strictly speeking a bug in playerctl. Instead it seems that gpmdp is sending data not conforming to the org.mpris.MediaPlayer2 protocol.

I used the tool dbus-mointor to get inspect some of the communication.
See this extract of a relevant section:

      dict entry(
         string "MinimumRate"
         variant             byte 1
      )
      dict entry(
         string "MaximumRate"
         variant             byte 1
      )

As you can see these datatypes are bytes (which are called type y in GLib) while the documentation specifies that the value should be a double.

Just to verify this I looked at an app that worked with playerctl (spotify) and it actually sends the specified datatypes:

      dict entry(
         string "Rate"
         variant             double 1
      )
      dict entry(
         string "MinimumRate"
         variant             double 1
      )

As a course of action I would recommend fixing this in gpmdp (I will actually do this).
But I also think that playerctl should handle incorrect data better, I will look into writing up a pull request for this.

@WolfangAukang
Copy link

WolfangAukang commented May 10, 2017

Hello, any update on this issue? I have seen GPMDP uses their fork of mpris-service, so maybe this can be helpful

EDIT: Strange, the shown types are the same as the ones required on MediaPlayer2. for example, line 273, where Volume settings are configured:

iface.addProperty('Volume', {
		type: Type('d'),
		getter: function(callback) {
			callback(that.volume || 1);
		},
		setter: function (value, next) {
			that.volume = value;
			that.emit('volume', value);
			next();
		}
});

@hatzel
Copy link

hatzel commented May 11, 2017

I took a deep dive into this issue but I didn't really get anywhere. This issue explains the underlying problem in node dbus, but nobody there is answering and it is not an easy fix.

I am no longer using gpmdp so I lost interest, sorry.

@fcastilloec
Copy link

As a workaround, at least only for Rate, MinimumRate and MaximumRate. I'm passing the value 1+1e-15. This prevent dbus from thinking it's a byte or even an int, and mpris sees the value as a 1 anyway.
For the position, that has no fixing on this side, only on the dbus module itself, or mpris module switching to a different dbus module that implements int64

@YodaEmbedding
Copy link

YodaEmbedding commented Jun 3, 2018

@acrisci
Copy link
Member

acrisci commented Mar 19, 2019

I fixed it!

https://dubstepdish.com/index.php/2019/03/17/the-great-node-mpris-project/

@acrisci acrisci closed this as completed Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants