search

FichteFoll / discordrp-mpris

Discord Rich Presence through media players providing the mpris2 dbus interface
MIT License
86 stars 19 forks source link

smplayer support #7

Closed BobbyWibowo closed 3 years ago

BobbyWibowo commented 6 years ago

I tried SMPlayer just now and turned out its reported "length" value was a float instead of an int, so it would crash due to this line expecting int but got float.

Here's a nice svg if you want to add the icon: https://en.wikipedia.org/wiki/File:SMPlayer_icon.svg.

* Odd things happened to my mpc-qt installation, which I could not figure out how to solve, so I switched to SMPlayer.

BobbyWibowo commented 6 years ago 
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 306, in <module>
    sys.exit(main())
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 292, in main
    loop.run_until_complete(wait_task)
  File "/usr/lib/python3.6/asyncio/base_events.py", line 468, in run_until_complete
    return future.result()
  File "/usr/lib/python3.6/asyncio/tasks.py", line 358, in wait_for
    return fut.result()
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 287, in main
    return loop.run_until_complete(main_task)
  File "/usr/lib/python3.6/asyncio/base_events.py", line 468, in run_until_complete
    return future.result()
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 280, in main_async
    return await instance.run()
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 79, in run
    await self.tick()
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 97, in tick
    player = await self.find_active_player()
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 184, in find_active_player
    groups = await self.group_players(players)
  File "/home/USER/src/discordrp-mpris/discordrp_mpris/__main__.py", line 246, in group_players
    state = ampris2.PlaybackStatus(await p.player.PlaybackStatus)  # type: ignore
  File "/home/USER/.local/share/virtualenvs/discordrp-mpris-hFD5vVOH/lib/python3.6/enum.py", line 291, in __call__
    return cls.__new__(cls, value)
  File "/home/USER/.local/share/virtualenvs/discordrp-mpris-hFD5vVOH/lib/python3.6/enum.py", line 533, in __new__
    return cls._missing_(value)
  File "/home/USER/.local/share/virtualenvs/discordrp-mpris-hFD5vVOH/lib/python3.6/enum.py", line 546, in _missing_
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 'Unknown' is not a valid PlaybackStatus

I'd also occasionally get this error when seeking with SVP turned on. Seeking typically takes slightly more time with it enabled, perhaps it got something to do with it.

FichteFoll commented 6 years ago

Well, those are both upstream bugs from smplayer through violation of the mpris2 protocol. Although it seems they don't update their code respository anymore(the last change on their sourceforge is from 2013), the bug tracker seems to be used still.

I'd try filing these as upstream issues first before I add workarounds here. I hope you're not on a distro with archaic packages, so that you can benefit from an upstream fix quickly. However, looking at the spec for "PlaybackStatus", it says:

May be "Playing", "Paused" or "Stopped".

, which doesn't rule out other values, so implementing a fallback for other cases sounds reasonable. Casting timestamps from the position and length metadata also wouldn't be that much of an issue. They are explicitly specified as (signed) 64-bit integers, though. (https://specifications.freedesktop.org/mpris-spec/2.2/Player_Interface.html#Property:Position, https://dbus.freedesktop.org/doc/dbus-specification.html#basic-types, https://www.freedesktop.org/wiki/Specifications/mpris-spec/metadata/#index2h4)

Thanks for the icon, I'll add that.

BobbyWibowo commented 6 years ago

Although it seems they don't update their code respository anymore(the last change on their sourceforge is from 2013), the bug tracker seems to be used still.

Ah, they maintain their code in their SVN repo now it seems: https://app.assembla.com/spaces/smplayer/subversion/source/HEAD/smplayer/trunk. At least that's the only one they linked in their Downloads page (tho it seems they still use the SourceForge to host installation files).