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

Generating the player support table #7

Open
ungive opened this issue Jan 28, 2025 · 2 comments
Open

Generating the player support table #7

ungive opened this issue Jan 28, 2025 · 2 comments

Comments

@ungive
Copy link
Member

ungive commented Jan 28, 2025

The player support table from the following link could be generated automatically:

https://github.com/ungive/discord-music-presence/blob/master/documentation/supported-media-players.md

Relevant discussion quoted from this issue: ungive/discord-music-presence#151

About the support list, I was meaning to generate it based on the repository, one could write a script or Invoke task (in tasks.py or a separate file) that generates the Markdown table for supported players. Maybe that's something you want to look into too, if you have the time? Right now it's quite manual work that is error-prone.

@smiba:

The overview should be easy, but I'm not entirely certain what the best way would be for the entire table.
Might be possible if we describe the level of support for a player in the player files?

✅ and "..." are simple and we already have all the information we need to generate those, but I don't believe ✖️ (and the other more > specific states) are currently written down in any machine readable files.

Basically:

  1. Do you think it might be a good idea to store player support in the player yaml files?
  2. How would we deal with comments about certain players like how to configure them etc. (also include them in the yaml files?)
@ungive
Copy link
Member Author

ungive commented Jan 28, 2025

I think I would add additional information to each player's yaml that says whether the player reports song information or not for a given platform (this allows differentation between "..." and "✖️") and if it:

  1. requires additional steps (e.g. mpv, settings need to be adjusted, default settings don't work),
  2. requires an additional plugin to work (e.g. MusicBee) with the link to it,
  3. needs an external application to run beside it (e.g. iTunes-SMTC or beefweb for foobar2000 on Linux), or
  4. has alternative plugins (or external applications) that are not mandatory (e.g. foo_mediacontrol for foobar2000) but which improve what is reported to the operating system.

I don't think the file should contain what metadata the player exactly reports and what it is not being reported as that is (1) a lot of work to maintain and (2) can change and get outdated pretty quickly.

Here's an idea for a new root key support in the player's yaml file:

id: foobar2000
support:
  win_winrt:
    - setting:
        - Go to "Advanced" preferences
        - Under "Display" enable "Integrate with Windows Universal Volume Control"
    - plugin:
        url: https://github.com/ungive/foo_mediacontrol
  lin_mpris:
    - program:
        url: https://github.com/ther0n/beefweb_mpris
id: mpv
support:
  win_winrt:
    - setting:
        - Add "media-controls=yes" to "mpv.conf"
    - setting:
        - Run with the command line argument "--media-controls=yes"

Logic: If the platform key (e.g. win_winrt) is present under sources, the player is supported on that platform. If the platform key is present under support, then additional steps are needed to get it working on that platform. If that platform is not under support, then it works out of the box. The platform key under support contains a list of ways to enable support for that player (where "support" means it reports sufficient metadata to the operating system). The first item in that list should be the suggested and least complicated way to get it working. There should be different types of settings, e.g. "setting" for a simple setting in the media player, "plugin" for a plugin/extension that can be added to the player and "program" for an external program that needs to run along-side the media player. Another key "instructions" with a list of strings might make sense for generic instructions in case none of the other types are suitable.

I envision the desktop app to contain these instructions at some point and to have another key in the player's yaml files for executable names on each operating system, so that Music Presence can detect when a player is running (by monitoring processes) without it needing to play media and then be able to show instructions for how to get these players working with Music Presence when there's instructions for it under the "support" key. See #8

@smiba
Copy link
Contributor

smiba commented Jan 28, 2025

Sounds good, I'll see if I have time to work on this as I think it should be pretty doable.
I'll be on holiday in a few days though so it might be a while, if you feel like picking this up in the meanwhile obviously feel free to but otherwise I'll see what I can do :)

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

2 participants