Wrong types for some properties

[jck]

Using the latest version,

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

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

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

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

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

[emersion]

I cannot reproduce... Can you provide your source code please?

[jck]

Here it is: https://github.com/twolfson/google-music-electron/blob/master/lib/mpris.js

[emersion]

And does the player work properly? Is there a problem with volume or position?

[jck]

The player works properly. The problem is that client's cannot access Rate because it does not match the expected type.

[emersion]

Can you check with the latest version please?

I cannot reproduce with GNOME 3.16.

[ldeichmann]

I looked into this some time ago, as far as I understood, the problem is node-dbus and the way it tries to intelligently convert JavaScripts float64 into different types, which is happening here https://github.com/Shouqun/node-dbus/blob/master/src/encoder.cc#L28-52
It doesn't seem to care about the type you specify, it just looks at the values. The Byte detection code

if(number >= 0 && number <= 255) {

eats all of your values, causing them to become type y in dbus.

[jck]

@PezaM , I noticed that you made some changes to the file you mentioned in node-dbus. Did you fix the issue?

[ldeichmann]

No, sorry, that doesn't fix the type y issue, fixed another one that occured before. Type y would take way more work than that

[jostrander]

I was going to open a new issue, however this one almost matches the description entirely. Currently facing a bug where the Metadata 'mpris:length' is expected to be an int64 (type x), but is currently marshalled to uint32. I've spent the better half of my morning diving into node-dbus only to figure out that the signal is only 'a{sv}', where v is the metadata object, and there's no way to provide signatures for each property in the metadata. Is this something you can see that would be fixable maybe via 'on the fly' instrospection?

[emersion]

Seems that this code is here: https://github.com/Shouqun/node-dbus/blob/master/src/encoder.cc#L80

I really don't know how to do this :-(

[jostrander]

Yeah, I've opened an issue in that repo for this as well, and I thought we had solved it, but then I went to implement and it didn't work, which lead me to this issue. I'll explain what I found on that one over there and see if they might be able to troubleshoot some more.

[fcastilloec]

Has there been any progress on this? I can't get the position of my track because it's the wrong type.
I have a work around for rate, minimumRate and maximumRate, since my app can't have different rates and should be always 1, I store it as rate=1+1e-15 and the same for the other ones. This prevents it from being stored as byte and for mpris it's shown as a 1
But there's nothing that I've come up with that can store something as type x (int 64), any ideas?

EDIT: @emersion the code in node-dbus can test for long (long.js) and make the dbus module depend on long. This will solve the issue. I'm not a programmer so I don't know how easy would be to implement. dbus-native already uses this. So whatever is easier, patch/fork dbus to use long or switch to dbus-native