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

Update mpris implementation #279

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@acrisci
Copy link

commented Mar 9, 2019

Add a basic mpris implementation by updating to mpris-service 2.0 and
uncommenting old mpris code.

Ref #98

@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 9, 2019

TODO:

  • a getter to return the position in the current track when requested from dbus
  • a player event when the track seeks to a new position
  • a way to set the volume on the player
  • a way to know when the volume changes
  • a way to set the shuffle status on the player
  • a way to know when the shuffle status on the player changes
  • a way to get the loop status of the player
  • a way to know when the loop status of the player changes
  • a way to open a file from a uri
@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 9, 2019

I think there will be conflicts with #278. We'll need to reconcile the changes in your and @charjac pull request to minimize the duplicated work.

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 15, 2019

Api is ready to go.

Update mpris implementation
Add a basic mpris implementation by updating to mpris-service 2.0 and
uncommenting old mpris code. Add additional methods to respond to mpris
queries and methods to get and set the shuffle status, loop status, and
position of the player.

fixes #98

@acrisci acrisci force-pushed the acrisci:mpris-update branch from a4f2202 to dad078f Mar 16, 2019

@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 16, 2019

Ok ready for testing.

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2019

Fantastic, thank you for your contribution. I will test it as soon as possible.


module.exports = env => {
const entry = env && env.LINUX ? './server/main.dev.linux.js' : './server/main.dev.js';

return {
entry: entry,
resolve: {
alias: {
jsbi: path.resolve(__dirname, 'node_modules', 'jsbi', 'dist', 'jsbi-cjs.js')

This comment has been minimized.

Copy link
@nukeop

nukeop Mar 17, 2019

Owner

what's this?

This comment has been minimized.

Copy link
@acrisci

acrisci Mar 17, 2019

Author

I'm not sure I need to look into why this works. @martpie came up with this. See this issue on mpris-service.

This comment has been minimized.

Copy link
@martpie

martpie Mar 17, 2019

JSBI ships with a .mjs version of the library. The thing is Webpack's electron-main will try to import this .mjs instead of the classic common JS file. Then things goes terribly wrong.

To me, this solution is a hack, but I am not sure if the problem comes from jsbi builds, or node-dbus-next (which seems to be written in cjs, but without a transpiler/bundler).

I am also looking for a better solution, but I can't manage to get this library working is the first place 😄 so this is not my top-priority.

@acrisci acrisci changed the title [WIP] Update mpris implementation Update mpris implementation Mar 17, 2019

@acrisci acrisci referenced this pull request Mar 18, 2019

Open

Player implementation status #30

7 of 8 tasks complete
@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 18, 2019

I was just looking for a program to use mpris from the terminal, and found playerctl. Only after reading the readme and clicking the author's profile did I realize that it's you. Small world, or maybe you're just the most prominent in that niche.

@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 18, 2019

My thing is that I primarily do community-driven Linux Desktop projects 😎

This is part of a big project I'm doing to support mpris on electron players. It was inspired by people complaining on the Playerctl issue tracker that electron players don't work. I wrote about it here:

https://dubstepdish.com/index.php/2019/03/17/the-great-node-mpris-project/

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 18, 2019

I also found out that dbus doesn't play nicely with tmux (apparently this combo causes an invalid socket location being saved in the environment, breaking playerctl).

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 18, 2019

2019-03-18-223726_677x431_scrot

Have you seen something like this before?
This occurs on launch and is apparently caused by dbus-next, although it might be something on my end.

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 18, 2019

Yep, it can't connect to dbus at all.

@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 18, 2019

Ah ok you're running a code path I haven't tested in dbus-next.

What is the value of $DBUS_SESSION_BUS_ADDRESS?

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 18, 2019

unix:abstract=/tmp/dbus-pSgvVqOdpL,guid=1b9bd7435b409b88d4058c195c900e3d

@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

I can reproduce this by launching a shell with dbus-launch which uses the abstract socket scheme by default (dbus-launch /bin/zsh).

I'm pretty sure this is a problem with electron disabling some node api for the filesystem.

GPMDP works ok with the abstract socket code path, so that's promising. I'm trying to see if there are differences in the webpack or electron configuration that get this to work.

The origin of the error is here within the node-bindings library, a dependency of the node abstract-socket library.

They are trying to get the name of the file to find the abstract-socket bindings using the node Error class and getting a stack trace.

However, the stack trace object (st[i].getFileName() below) is returning undefined so it can't build the search path properly. I think if this function worked, then this bug would be fixed.

  Error.prepareStackTrace = function(e, st) {
    for (var i = 0, l = st.length; i < l; i++) {
      fileName = st[i].getFileName();
      if (fileName !== __filename) {
        if (calling_file) {
          if (fileName !== calling_file) {
            return;
          }
        } else {
          return;
        }
      }
    }
  };

  // run the 'prepareStackTrace' function above
  Error.captureStackTrace(dummy);
@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

Here is an issue on the node-bindings repo with a similar issue. This seems to be related to webpack doing some sort of eval on the bindings library. This issue seems to have been resolved in another project here. I tried just setting the webpack node config to

node: {
  __filename: true,
  __dirname: true
}

That allows fs to be used, but still doesn't resolve the issue so there might be more to it.

Exclude bindings and abstract-socket from bundle
The abstract-socket dependency cannot be used in a bundle because it
uses logic to find the bindings depending on a location in the
filesystem within the node_modules directory
@acrisci

This comment has been minimized.

Copy link
Author

commented Mar 22, 2019

Ok, so the real issue is that abstract-socket and bindings cannot be put in the bundle because the logic to find the bindings depends on the location of abstract-socket within the node_modules directory. And you can't include the compiled file in the bundle anyway.

I wish we didn't have to include this compiled file, but nodejs does not natively support abstract unix sockets so I don't see a way to write this dependency out.

This fixes the issue, but I'm not sure what the implications of using externals in the webpack config is.

I hope this doesn't put you in a bad spot.

@nukeop

This comment has been minimized.

Copy link
Owner

commented Mar 22, 2019

Does this work when we build the whole program in an Appimage, snap, etc? The whole problem with native dbus implementation was that it was impossible to bundle it correctly for these build targets, and it caused more trouble than it was worth. I'm fine if we have to use some black magic to get it to work, I'll test it later today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.