MPRIS - Full standards imlementation request

[VastOne]

Requesting full MPRIS standards to be implemented. 

Standards can be reviewed here http://xmms2.org/wiki/MPRIS

Specifically the metadata and GetMetadata standards ...

With these, I could include Gmusicbrowser in the conky scripting I have setup for several other players. These scripts bring the dbus information to the conky screen using standard MPRIS protocol.  This would bring in many Conky users who look for this in their players

Full MPRIS is a feature in all major players.

For me, I love gmusicbrowser, but will not use it without this feature.

Thank you.

[Quentin Sculo]

Have you tried the mpris1 plugin included in the beta v1.1.6 ?
It should work, if there is a field you are missing, tell me about it.

I also have an almost finished mpris2 plugin, but it's currently on hold, as I wanted to test it with ubuntu's SoundMenu, but it's a bit more complicated to make the SoundMenu stuff work that I hoped  (it requires a library that has no perl bindings, but it may be possible to make it work with a few DBus methods, I'm not sure)

[VastOne]

I have tried the plugin but it does not have any of the following:

album
artist
arturl
bitrate
genre
location
mtime
time
title

that are standard in the GetMetadata

I use D-Feet D-Bus Dbugger and it shows the mpris/dbus  settings from gmusicbrowser  and there is no GetMetadata function at all

This command shows what a player that does have it, in this case Guayadeque, when run from a command line and is mirrored in D-feet D-Bus

Code Select Expand


[code]dbus-send --print-reply --dest=org.mpris.guayadeque /TrackList org.freedesktop.MediaPlayer.GetMetadata int32:0

This is the terminal outcome of that command and where the data from the scripts I write come from

method return sender=:1.404 -> dest=:1.576 reply_serial=2
   array [
      dict entry(
         string "location"
         variant             string "file:///media/storage/Music/mp3new/Classic Rock/'Til Tuesday/'Til Tuesday - Coming Up Close.mp3"
      )
      dict entry(
         string "title"
         variant             string "Coming Up Close"
      )
      dict entry(
         string "artist"
         variant             string "'Til Tuesday"
      )
      dict entry(
         string "album"
         variant             string "'Til Tuesday"
      )
      dict entry(
         string "time"
         variant             int32 283
      )
      dict entry(
         string "mtime"
         variant             int32 283000
      )
      dict entry(
         string "genre"
         variant             string "Classic Rock"
      )
      dict entry(
         string "bitrate"
         variant             int32 167
      )
   ]
[/code]

And again this is mirrored in D-Feet D-Bus

In Gmusicbrowser there is no function for the GetMetadata.

I am using the latest version 1.1.6 that was I pulled from the deb posted on WebUpd8 here

http://www.webupd8.org/2011/01/install-gmusicbrowser-116-in-ubuntu.html

Thank you

[Quentin Sculo]

yes, there is a small bug with the DBus perl bindings that gives troubles to d-feet, it only shows the root object "/" and not the Player and TrackList object. I have yet to report the bug to the perl module author :(

Other than that it works for me, it has all the fields you listed, except the genre field (because gmb support multiple genres for each song, and I think mpris1 doesn't say how it should be handled)

Code Select Expand

dbus-send --print-reply --dest=org.mpris.gmusicbrowser /Player org.freedesktop.MediaPlayer.GetMetadata
method return sender=:1.89 -> dest=:1.101 reply_serial=2
   array [
      dict entry(
         string "location"
         variant             string "file:///home/squentin/Music/Lhasa/Lhasa/Lhasa%20-%20Lhasa%20-%2009%20-%20The%20Lonely%20Spider.mp3"
      )
      dict entry(
         string "time"
         variant             uint32 198
      )
      dict entry(
         string "mtime"
         variant             uint32 198000
      )
      dict entry(
         string "arturl"
         variant             string "file:///home/squentin/Music/Lhasa/Lhasa/cover.jpg"
      )
      dict entry(
         string "audio-bitrate"
         variant             uint32 320
      )
      dict entry(
         string "tracknumber"
         variant             string "9"
      )
      dict entry(
         string "album"
         variant             string "Lhasa"
      )
      dict entry(
         string "artist"
         variant             string "Lhasa"
      )
      dict entry(
         string "comment"
         variant             string ""
      )
      dict entry(
         string "audio-samplerate"
         variant             uint32 44100
      )
      dict entry(
         string "title"
         variant             string "The Lonely Spider"
      )
      dict entry(
         string "disc"
         variant             uint32 1
      )
      dict entry(
         string "year"
         variant             uint32 2009
      )
      dict entry(
         string "album_artist"
         variant             string "Lhasa"
      )
   ]

[VastOne]

Thank you... I should have run my own dbus command not depended solely on D-Feet..

I apologize for this...
I will work on the scripts and should have them ready shortly..

I appreciate the help and GMusic B!!

[VastOne]

I have an additional question on this...

Can you explain a bit how the cover art is pulled?  It seems as if it does not follow the standard getcoverart

Most players take the cover image to the /tmp directory in some form,  but GMB seems to locate and find whatever first one it can in the directory structure...

It also does not seem to find embedded art, but that is what my scripts do..

If you want i can send you a script showing you what I mean...

BTW, everything else MPRIS works perfectly... thanks!

[Quentin Sculo]

It returns the file that is set as the cover for the album in gmb.
But embedded pictures are not returned, because I'm afraid it would confuse most program trying to display the file (I asked the guys writing mpris2, they were not sure what to do in the case of embedded pictures).

The problem with writing the picture in a file in /tmp/, is that it only works well with one picture, if a mpris client asks for a lot of pictures, it gets a bit messy : should it write it all in the same file, and assume the client has read it between each request ? Or write them all to different files, but then who delete them and when ?

[VastOne]

I am not sure how an mpris client would ask for a lot of pictures. Again, as far as embedded, I can give you the way it is done in the Python scripts I work with and I am sure you could easily see and use it in Perl...

Any of the other players writes it to the /tmp as cover, simply overwriting itself at each track change.

But my question is, where is it writing it to now?  If I have that location, with my scripts I can change to that location and have Conky display it.  It does not need to be /tmp, but it must be storing it somewhere?

Thanks... I do appreciate the answer - There is a lot of Conky users who look for this from a player, and I know I would use GMB exclusively once I get this to work

[Quentin Sculo]

I am not sure how an mpris client would ask for a lot of pictures.

Yes, usually mpris client only care about the current song, but it is possible a mpris client would want to query properties for all the playlist, or for a bunch of songs. Of course asking for thousands of songs one at a time could take a while...

But my question is, where is it writing it to now?

Now it is not writing it anywhere. When an album is added it tries to find a picture by looking for embedded pictures or picture files in the same folder as the songs, and store this location. The user can set it to another picture from the album context menu, and there is a plugin to search and download a picture from the web.
When asked by a mpris client, it simply use the stored location.
I actually thought the mpris1 plugin didn't return anything in the case of embedded pictures, but I was wrong, I've done this in the, as of yet not released, mpris2 plugin.
The mpris1 plugin simply returns the location as stored in gmb, which in the case of embedded pictures may include a ":1" or ":album" at the end of the filename (used to select the picture in the case more than one picture is embedded). I should probably remove this.

[VastOne]

Thanks for the explanations...

One other thing of note, GMB will find the next available image in an apparent search through the directories, if the current directory does not have an image file or embedded.

Thanks, I will try a different approach with the Conky scripts..

[VastOne]

I have to ask for further info on this.. and this may be a bug..

I am playing a track now and it definitely has a cover.jpg in it's directory, but GMB is going to a completely different directory to get a different cover.jpg.  This is bizarre because there is no logic in why it is going to this specific directory which is light years and thousands of files away from the current song

This is happening in essentially all of my tracks.

Edit: I realize now in reading through some things that GMB basically takes the approach of Album to cover art and not the individual directory.  So in the scan it is finding only the Album cover art which in my case could be scattered across my Genre based directory setup...