D11366: [WIP] MPRIS control plugin: fix status init

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Thu Mar 15 23:19:37 UTC 2018


kossebau added a comment.


  In D11366#226774 <https://phabricator.kde.org/D11366#226774>, @mtijink wrote:
  
  > Are you sure this is needed? It appears to transfer CanPause etc. just fine when I start an MPRIS player, without the patch.
  
  
  From the debug logs I looked at, I would still think this is needed. Even if it seems just one of a few issues which might need fixing.
  
  While most players will change some of the properties after having been started, thus trigger the update signal, they do not need to do. Or if the KDE Connect MPRIS plugin is activated if the player is already running, then there might be even less state changes with related propertychanged signals coming in.
  
  I left a qDebug() log in the updated (no longer crashing patch) which should show what I mean.
  
  There also seems another issue which can be seen by that log: when closing and then starting a player again, there will be multiple invocations of `MprisControlPlugin::propertiesChanged(...)`, as many times as the player had been restarted. Possibly the `OrgFreedesktopDBusPropertiesInterface` & `OrgMprisMediaPlayer2PlayerInterface` instances need some manual cleanup if a service disappears, otherwise they pile up for the same service name. But would be an orthogonal issue to the problem I am looking at.
  
  > Do I need the git-master gwenview to reproduce the issue?
  
  Yes, from as latest master as possible, D10972 <https://phabricator.kde.org/D10972>, which brought the MPRIS stuff to gwenview, only landed a day ago.
  
  It seems that the set of MPRIS data used is resulting in unexpected states with the Android KDE Connect media payer remote control plugin. Which then shows almost no buttons for the actions.
  Sadly I have never done Android code, so cannot tell what could be wrong or even try to come up with patches. I just can tell that the Plasma media controller plugin works perfectly with Gwenview, so my initial working theory is that the issues are not in Gwenview :)
  
  > In D11366#226760 <https://phabricator.kde.org/D11366#226760>, @kossebau wrote:
  > 
  >> Actually not yet completly tested, currently fighting to get my custom kdeconnect-kde build running. Seems installs of D-Bus service files into custom folders hides them from dbus server, despite being in XDG* var paths, so kdeconnectd is not started. Any hints how to solve that?
  > 
  > 
  > You can start `kdeconnectd` manually (located in `build/daemon`). Not sure how it picks up plugins etc. in that case though.
  
  Thanks. Turned to something similar meanwhile, starting the custom installed one manually in a shell, also to get all debug log there.

REPOSITORY
  R224 KDE Connect

REVISION DETAIL
  https://phabricator.kde.org/D11366

To: kossebau, #kde_connect
Cc: mtijink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20180315/fbf96cc7/attachment-0001.html>


More information about the KDEConnect mailing list