Topic: MC21 not preventing system standby during playback (Read 9238 times)

terrym@tassie · « **on:** August 16, 2015, 03:05:07 am »

I am having a problem where MC21 does not prevent the system from going into standby during playback. Reporter shows Playback (disable automatic sleep) but the system goes into standby at the time set in the power manager.

Debian 8.1 AMD64 with Xfce4 desktop and power manager.
MC21 is being used as a client so no local file access is occurring.

New to using MC on Linux, is there anything I need to do to configure the power manager?

mwillems · « **Reply #1 on:** August 16, 2015, 12:39:29 pm »

I have the same issue, I don't think JRiver has revised it's power management signals for systemd. Power management/blocking suspend is different in systemd than it was under the old system.

The documentation is here: http://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
http://www.freedesktop.org/wiki/Software/systemd/inhibit/

I keep meaning to script something to deal with it using the new inhibitor system (it's trivial to query MC's web interface to determine if something is currently playing), but I haven't worked with this systemd module before, ~~I'm not sure that all desktop environments have fully implemented the functionality (XFCE had not as of last year, but that may have changed)~~, and I'm lazily hoping the MC team will sort it out

EDIT: looks like it's implemented in XFCE now (as well as gnome and KDE): https://wiki.archlinux.org/index.php/Power_management#ACPI_events

terrym@tassie · « **Reply #2 on:** August 16, 2015, 04:57:49 pm »

Thanks for the info, yes I can confirm I see the same issue if I use the Gnome desktop.
Also no block is being listed for Mediacenter21 (systemd-inhibit --list).

JRiver devs- any timescale for resolution of this issue?

A very quick and dirty work-around for me is to start my MC21 session using systemd-inhibit so that it blocks sleep until I terminate the session, at least that way the music doesn't suddenly cut off!

Edit: To my surprise the above didn't work, although it was listed as having a block.

Guess I'll have to wait for a proper fix and disable standby while using MC21.

bob · « **Reply #3 on:** August 17, 2015, 02:32:25 pm »

The Options->Audio->Settings->Disable display from turning off (useful for HDMI audio) option might help keep the system from sleeping.

mwillems · « **Reply #4 on:** August 17, 2015, 02:42:53 pm »

Quote from: bob on August 17, 2015, 02:32:25 pm

The Options->Audio->Settings->Disable display from turning off (useful for HDMI audio) option might help keep the system from sleeping.

On Arch, I don't see an inhibitor lock from MC when I use that option (and my display doesn't stay on). I assumed the issue was related to the new inhibitor framework in systemd.

Bob are you saying that that option is working correctly for you on Jessie? If so that points to something other than systemd as the culprit.

bob · « **Reply #5 on:** August 17, 2015, 02:57:16 pm »

Quote from: mwillems on August 17, 2015, 02:42:53 pm

On Arch, I don't see an inhibitor lock from MC when I use that option (and my display doesn't stay on). I assumed the issue was related to the new inhibitor framework in systemd.

Bob are you saying that that option is working correctly for you on Jessie? If so that points to something other than systemd as the culprit.

Haven't tried it on Jessie yet.
It's using
xset
to set the display sleep and DPMS.

That's pretty basic stuff.
You can do an

xset q

from a terminal to see the current settings.

terrym@tassie · « **Reply #6 on:** August 17, 2015, 04:36:34 pm »

Quote from: bob on August 17, 2015, 02:32:25 pm

The Options->Audio->Settings->Disable display from turning off (useful for HDMI audio) option might help keep the system from sleeping.

Tried this on both 32bit and 64bit Debian Jessie 8.1 with no luck, DPMS shows as disabled using xset q but it seems to have no effect, system still idles to sleep.

bob · « **Reply #7 on:** August 18, 2015, 05:29:58 pm »

I'm not seeing a way to turn this on and off programatically,
dpms is a extension of X11 which allows us to control the display, I see no such power managment extension to X11.

I'm surprised that the open desktop systemd-inhibit doesn't work with MC. That sounds like a system bug.

mwillems · « **Reply #8 on:** August 18, 2015, 05:47:57 pm »

Quote from: bob on August 18, 2015, 05:29:58 pm

I'm not seeing a way to turn this on and off programatically,
dpms is a extension of X11 which allows us to control the display, I see no such power managment extension to X11.

There isn't one; power management is almost exclusively handled by the logind component of systemd now, and Gnome, KDE, and XFCE's power managers all interface with logind in current versions.

Quote

I'm surprised that the open desktop systemd-inhibit doesn't work with MC. That sounds like a system bug.

It seems to work here when I run systemd-inhibit as a privileged user, but when run as a normal user Gnome-power-manager just ignores it and suspends anyway. The documentation mentions that taking inhibitor locks is a privileged operation (and that privileged users can bypass the locks), but (perversely) the command line utility will register an inhibitor lock even without privileges. The unprivileged lock just doesn't actually work (at least Gnome doesn't respect it).

So I'd advise testing by placing the lock with sudo or as root and seeing if that works. To avoid running MC as root, try executing

Code: [Select]

sudo systemd-inhibit sleep 3600Or something like that (assuming your suspend timeout is less than an hour). That worked here, and if you can establish how to get a lock, we're halfway to at least a workaround solution

I need to do some more testing, but I have a half baked script solution that avoids running MC as root. Basically it just queries MCWS once a minute to see if something is playing, and if so executes as root

Code: [Select]

systemd-inhibit sleep 70Then the script waits sixty seconds and then tries again (or could be run with cron once a minute). It's only half written and scarcely tested (because the minimum idle suspend timeout on Gnome is 15 minutes, so testing takes forever).

The "real" solution though is to write an appropriate wake-lock using the dbus API; I'm trying to dig through it, but not getting very far. I assume that API must work as there are a number of apps (like Caffeine) that successfully use it to prevent sleep. See e.g. the freedesktop inhibitor here: http://bazaar.launchpad.net/~caffeine-developers/caffeine/main/files

Mike Noe · « **Reply #9 on:** August 18, 2015, 06:20:10 pm »

@mwillems:
I've been using d-bus for some stuff here and I've been playing around with this session bus service ever since Plasma5 shows on the notify icon which apps are "inhibiting" (it's cool):

org.freedesktop.PowerManagement.Inhibit

Interface "org.freedesktop.PowerManagement.Inhibit" under object "org/freedesktop/PowerManagement" that has the following methods:

Inhibit()
UnInhibit()
HasInhibit()

Also easy to connect the signal HasInhibitChanged() (under the same interface) to find out the changes.

This is all implemented by the KDE daemon, I believe, as the standard, so shouldn't this be implemented on each DE that supports the freedesktop standards?

mwillems · « **Reply #10 on:** August 18, 2015, 06:25:05 pm »

Quote from: Mike Noe on August 18, 2015, 06:20:10 pm

This is all implemented by the KDE daemon, I believe, as the standard, so shouldn't this be implemented on each DE that supports the freedesktop standards?

The dbus interface should work (at least on KDE, Gnome, and XFCE), which is why I mentioned that the dbus method is the "right" way to do it. I just have never interacted with dbus before and have no idea how dbus calls/methods even work (I'm not a pro at this, I'm just paddling around).

I don't think MC currently even tries to submit an inhibitor lock, I'm talking about scripting workarounds.

Mike Noe · « **Reply #11 on:** August 18, 2015, 06:40:48 pm »

Quote from: mwillems on August 18, 2015, 06:25:05 pm

The dbus interface should work (at least on KDE, Gnome, and XFCE), which is why I mentioned that the dbus method is the "right" way to do it. I just have never interacted with dbus before and have no idea how dbus calls/methods even work (I'm not a pro at this, I'm just paddling around).

I don't think MC currently even tries to submit an inhibitor lock, I'm talking about scripting workarounds.

Okay, yeah, gotcha, I'm using QT/KF5(C++) to write some apps right now...QT makes it quite simple to "hook up to the dbus" (I guess all the "frameworks" do, really). But basically, what you're doing in your script, I'm doing in my app. It checks the PlayingNow Info for each zone on the server(localhost), checks state and file type and then attempts the dbus call iff video is playing (and current inhibit status).

terrym@tassie · « **Reply #12 on:** August 18, 2015, 11:06:30 pm »

I also discovered that a lock could work if the command "sudo systemd-inhibit --what=sleep sleep 20m" is issued from the terminal but unfortunately after the lock is removed the system does not then suspend as normal. I also agree that the 15 minute minimum for suspend makes it an absolute pain for testing!

The caffeine dbus approach is surely the way to go with this, the gnome desktop extension version allows configuration of apps (such as vlc) to be added so it activates when they are started. This is not totally ideal as it just detects that the app is running and inhibits suspend for the whole time the app is running rather than just when play activity is detected.
Unfortunately MC does not even appear as one of the apps that can be selected to do even this basic level of suspend inhibit.

As I said in my OP I'm very new to Linux so delving into the inner workings and modifying desktop extensions to suit are still beyond me a this stage.

Looking at the javascript for the dbus method used by caffeine though, it really doesn't look like it should be too difficult for a C++ application like MC to use the dbus to perform sleep inhibit on all the major Linux desktops.
https://github.com/eonpatapon/gnome-shell-extension-caffeine/blob/master/caffeine%40patapon.info/extension.js

Mike Noe · « **Reply #13 on:** August 19, 2015, 06:24:08 pm »

if you guys are still playing around with scripting this, try using dbus-send with these "object paths" (I'm not really up on dbus-send syntax):

"org.freedesktop.PowerManagement", "/org/freedesktop/PowerManagement", "org.freedesktop.PowerManagement.Inhibit"
Use method "Inhibit" and pass two args (appname, reason) to set up the powermanagement inhibition
Use method "HasInhibit" to query that it was added (or in the case of of your DE, there might be a notification message of some sort)
Use method "Uninhibit" to remove the inhibition.

Seems to work here on openSuse Plasma5 but I'm doing it from an app....(the powermgt tray icon shows that my app is blocking power management features)

Code: [Select]

    QDBusInterface *interface = new QDBusInterface("org.freedesktop.PowerManagement", "/org/freedesktop/PowerManagement", "org.freedesktop.PowerManagement.Inhibit", bus, this);
    QDBusReply<uint> cookie = interface->callWithArgumentList(QDBus::Block, "Inhibit", QList<QVariant>() << "mcwsRemote" << "playing video");
    qDebug() << cookie;
    QDBusReply<bool> reply = interface->call("HasInhibit");
    qDebug() << reply;
.
.
.
    interface->call("UnInhibit", cookie.value());
.
.
    interface->deleteLater();

Edit: Oh yeah, if you haven't already found it, D-Feet is a great little tool for dbus work/play.

terrym@tassie · « **Reply #14 on:** August 30, 2015, 03:37:09 pm »

Can I just get clarification that this idling to sleep/suspend is only affecting Debian 8.1 Jessie (AMD64 and i386)?

It is a bit of a nuisance and when I moved my client PCs from Windows to linux I chose Debian distros as I thought they were the best supported distros for MC.
Would I be better using a different linux distro so I don't get this issue?
I equally don't want to go through the hassle of changing distros if this is about to be fixed in MC21- so any timescale for a fix?

My current workaround is to use the Gnome desktop with the caffeine extension and manually inhibit suspend (although I don't always remember to switch it off again) and Gnome is a bit cpu intensive for my old i386 netbook client.

It is pretty fundamental that a media player inhibits sleep during playback (though to be fair vlc doesn't on Debian 8.1).

Thanks

mwillems · « **Reply #15 on:** August 30, 2015, 03:55:56 pm »

Quote from: terrym@nz on August 30, 2015, 03:37:09 pm

Can I just get clarification that this idling to sleep/suspend is only affecting Debian 8.1 Jessie (AMD64 and i386)?

It definitely affects other distros (I can personally attest to Arch being affected). I suspect that any systemd-based distro would be affected, which is almost all modern distros (other than gentoo and slackware).

Based on what Bob was saying, things might be working on Debian Wheezy which was pre-systemd. I'm not sure I'd want to use Wheezy for a daily use system (although for a dedicated MC box it might be just fine).

terrym@tassie · « **Reply #16 on:** August 30, 2015, 06:37:14 pm »

@mwillems, thanks for the info, yes it seems a bit regressive to go back to Wheezy.

I guess if there isn't a fix for MC21 any time soon then I'll just have to get my head around Python scripting and write a workaround script that detects MC playing and use the dbus to inhibit suspend.

So @Bob is this likely to be fixed a) within 3 months, b) sometime in the lifespan of MC21 or c) never?

This will enable me to judge whether it is worth putting the effort into the work around, thanks.

bob · « **Reply #17 on:** August 31, 2015, 01:41:08 pm »

Quote from: terrym@nz on August 30, 2015, 06:37:14 pm

@mwillems, thanks for the info, yes it seems a bit regressive to go back to Wheezy.

I guess if there isn't a fix for MC21 any time soon then I'll just have to get my head around Python scripting and write a workaround script that detects MC playing and use the dbus to inhibit suspend.

So @Bob is this likely to be fixed a) within 3 months, b) sometime in the lifespan of MC21 or c) never?

This will enable me to judge whether it is worth putting the effort into the work around, thanks.

Love to change that and started on a fix (which should be easy) but I can't see how to prevent the sleep generically in the MC app even after reading the links above.
Perhaps someone would like to fill me in with more detail?

terrym@tassie · « **Reply #18 on:** August 31, 2015, 04:18:23 pm »

Hi Bob I am afraid the only help I can give is the following code stub for Python using the dbus:

Code: [Select]

import dbus
pm = dbus.SessionBus().get_object("org.freedesktop.PowerManagement", "/org/freedesktop/PowerManagement/Inhibit")
print(pm.HasInhibit()) # 0
inhibited = pm.Inhibit("Me", "I said so")
print(pm.HasInhibit()) # 1
pm.UnInhibit(inhibited)
print(pm.HasInhibit()) # 0

The other method is to call systemd-inhibit with privilege see http://www.freedesktop.org/wiki/Software/systemd/inhibit/

Hopefully some folks with a lot more programming knowledge and familiarity with linux can help with this one.
Mike Noe?

Mike Noe · « **Reply #19 on:** September 01, 2015, 10:31:07 am »

Quote from: bob on August 31, 2015, 01:41:08 pm

Love to change that and started on a fix (which should be easy) but I can't see how to prevent the sleep generically in the MC app even after reading the links above.
Perhaps someone would like to fill me in with more detail?

When you say "generically", do you mean a method that takes into account an install/distro that doesn't use a DE, ie. server mode only?

bob · « **Reply #20 on:** September 01, 2015, 11:55:09 am »

Quote from: Mike Noe on September 01, 2015, 10:31:07 am

When you say "generically", do you mean a method that takes into account an install/distro that doesn't use a DE, ie. server mode only?

That would be preferred.

Mike Noe · « **Reply #21 on:** September 01, 2015, 06:54:21 pm »

egads. Beyond my level of expertise.

For a DE present, seems like dbus is the way to go. Without a DE, systemd, pm-utils(deprecated?), etc., IDK.

EdwinM · « **Reply #22 on:** January 13, 2016, 04:03:48 am »

Any news about a fix for this issue in Debian 8.2.0.
I'm in the process of moving away from windows10 for different boxes, also for stability issues and broken windows dac drivers which keep me powercycling my jriver box.
For now the only solution I've figured out is to try it with debian 7.9.0 (the last wheezy if I'm correct). Can anyone confirm the sleep/resume works with this release
I hate the music cutting out so I've set the sleeptimer to 4 hours since that's probably the longest I listen to music without using jremote to switch to some other music. This is sort of a fix but not a real fix ....

INTERACT FORUM

Author Topic: MC21 not preventing system standby during playback (Read 9238 times)