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

Discussion: Prevent sleep mode on Windows while streams are running #78

Open
jonschz opened this issue Jan 11, 2023 · 20 comments
Open

Discussion: Prevent sleep mode on Windows while streams are running #78

jonschz opened this issue Jan 11, 2023 · 20 comments

Comments

@jonschz
Copy link

jonschz commented Jan 11, 2023

Continuing the discussion in jellyfin/jellyfin#9043 here.

As a quick recap, the underlying issue is that Jellyfin does not prevent Windows from automatically entering sleep mode after X minutes even when there are active streams. A decision was made to approach this issue in the tray app instead of the core. I have also written a proof-of-concept Jellyfin plugin here.

My question would be how to best incorporate a solution. The following ideas come to my mind:

  1. Jellyfin on Windows could be bundled with my plugin (or a similar one).
  2. The Windows tray app could be modified to implement this feature.
  3. The Windows tray app could be bundled with a plugin implementing this feature (this may be what @nielsvanvelzen meant, though I am not sure. Is it possible to install plugins for the tray app but not for the server, i.e. is there a separate plugin framework?)

Thanks in advance for your opinions.

@JPVenson
Copy link
Member

I think the only reasonable way would be to build that into the server itself or via a plugin. The tray app is optional and does not "know" what JF server is actually doing. That would be not the correct place in my opinion as it would also need some very tight integration apart from what its doing now.

@jonschz
Copy link
Author

jonschz commented Apr 26, 2023

Thank you for the response. The opinion of the members on jellyfin/jellyfin#9043 was different (unless I misunderstood them), what would be your suggestion on how to proceed?

On a related note, do you know if it is possible to bundle Jellyfin on Windows with a plugin pre-installed? Then only the Windows bundle, but not the tray app itself would need to be changed.

@JPVenson
Copy link
Member

JPVenson commented Apr 26, 2023

i would handle it like niels said: I am but one person doing stuff here :-).
My recommendation is to first push it as an plugin like any other. Dotnet has some nice tools to determine the underlying OS for exactly this usecase

System.OperatingSystem.Platform == PlatformID.Win32NT

https://learn.microsoft.com/en-us/dotnet/api/system.platformid?view=net-7.0

To check before you run your code. If the feature is to be desired by an Admin he can install it.
I see the idea of implementing it into the Tray app but as its only very loosely coupled with the actually JF server (it only starts and stops the process or the service) that would mean bringing a lot of communication into the very simple app.

@JPVenson
Copy link
Member

JPVenson commented Apr 26, 2023

Ok i maybe understand what niels meant.
It could be possible to give the tray app an new feature that pushes/downloads the plugin into the correct plugin folder and then restarts the JF server.
That would be an "Quick'n Easy" solution

@nielsvanvelzen
Copy link
Member

Yeah I think we can make it part of the installer to automatically add a "Windows support" plugin to the server. This plugin could add stuff specific for the OS like the "prevent sleep while streaming" option.

@JPVenson
Copy link
Member

JPVenson commented Apr 26, 2023

OK but if you want it to be installed by default, i see no functional difference of packing it into the default server install aswell and just running the code conditional. Would be 1 less step inbetween

@jonschz
Copy link
Author

jonschz commented Jul 19, 2023

As the discussion seems stale, I would like to kindly inquire whether there will be a continuation / resolution at some point?

If that seems unlikely, is there a chance that the current plugin (which @qwerty12 and I now consider feature complete) could, at the very least, become an official plugin despite its platform dependency? Should I be in touch on Matrix?

@kingp0dd
Copy link

kingp0dd commented Jul 19, 2023 via email

@anthonylavado
Copy link
Member

anthonylavado commented Jul 23, 2023

Should I be in touch on Matrix?

@jonschz Yes, please message/tag me and we'll get this in as a bundle for the Windows install.

@anthonylavado
Copy link
Member

@jonschz I was looking at this again, and realized that this repo has an MIT License, so I don't know how including your GPLv3 plugin works with that. I suppose it's no issue, since it's an already compiled module that I'd be including.

@jonschz
Copy link
Author

jonschz commented Sep 11, 2023

That is a good point. I would be happy to re-publish my code under MIT, and presumably @qwerty12 as well, but the problem is that the plugin template is GPL licensed (and I vaguely remember a note somewhere stating that all code linked against Jellyfin core has to be GPL as well).

In any case, I agree with your assessment that distributing the binaries is not an issue (not a laywer, though). On a different note, it should also be possible to change this repo's license to GPL if that is desired, only the reverse requires consent from all contributors.

@anthonylavado
Copy link
Member

I am going over it with the broader team. Because the plugin would be supplied as a compiled module, it should be fine.

That said, our macOS wrapper is MPL v2, and we'd probably want to be consistent here. I'll work on relicensing this Repo, and then we can work on bringing in the plugin as an official project as well.

@msimic
Copy link

msimic commented Nov 23, 2023

My opinion differs.
Even if we are talking about pure servers, they can be high availability servers or not and could be allowed to sleep and woken up.
Jellyfin is hardly a "high availability server". It is something that is required on demand occasionally and often used in a mixed mode environment with client and server together with perhaps additional clients like TVs.

In case they are allowed to sleep it is a duty of the software to indicate when sleep is not desired, which Jellyfin currently does not do.

On windows this can be by setting SetThreadExecutionState with ES_SYSTEM_REQUIRED periodically, on linux by sending the apropriate message to the dbus, and I'm sure there is a similar method for Mac.

Since doing so does not harm any functionality for a dedicated high availability server there is no reason to not have this in the core. "OS specific" is not a reason to exclude something from core functionality, but rather to implement it in an OS specific way for all supported OSes if the feature is important.

Carbon neutrality is important and should be the goal of any developer, including Jellyfin developers.

You cannot expect users to know or care about this, so it would be good for them to see this in the server settings UI probably enabled by default with explanations on what it does and why it is important and how to use with WoL. If they don't see this they will simply turn off sleep and keep increasing carbon emissions, which I'm sure tens of thousands are already doing because they know no better.

"User watches movie on TV, his computer goes to sleep during the playback and interrupts him"
"User turns off sleep on the computer - since there is nothing in the server playback settings for this"

This is what happens. Jellyfin should try to avoid this.

@JPVenson
Copy link
Member

@msimic

Jellyfin runs on dotnet so it would require code for all operating systems including linux flavors including mac, to be implemented and supported. Which is just outside the scope of what JF wants to do. If you configure your server to go to sleep after X time, then it should do that its mostly a feature on UI servers. If you configure your sever to go into low power, it will when there is nothing to do.

Jellyfin is not responsible for management of your server, you are. The idea that was flowing around here was to make it part of the system tray app that runs on windows alone, which is a compromise. Apart from that, jf may stop the server from hibernation but could never start it back up, which in my opinion is a halve solution anyway so we should not really get too deep into it.

@msimic
Copy link

msimic commented Nov 30, 2023 via email

@JPVenson
Copy link
Member

I am curious how you would send a magic packet, via web, via the internet to a computer.

There is currently a PR that aims to either create a new or improve the existing api to get knowledge of currently running streams. So utilizing that you could handling your usecase yourself by getting that info and stopping the server yourself.

@msimic
Copy link

msimic commented Nov 30, 2023 via email

@cvium
Copy link
Member

cvium commented Nov 30, 2023

Wake On Lan does need a magic packet. Maybe some manufacturers have decided to allow pings, but that is not standard.

We are not here to save the world nor do anything we do have the slightest impact (we do not have the user base). It's a terrible argument (following that line of thought we should remove transcoding), and it has already been shown that plugins can provide the "prevent sleep" functionality.

If you want to reduce your carbon footprint, you can start by looking at eating habits, clothes and general consumerism.

@msimic
Copy link

msimic commented Nov 30, 2023 via email

@sevenrats
Copy link
Member

the ethtool docs themselves confirm that not all options are supported on all devices, so this is not an option on linux. It's probably not a viable option on Windows either. Since they have no way of magically supporting devices that don't physically support it, in all likelihood windows just silently fails when the hardware doesn't support it. thats what they do with all their other fake/noop settings.

wol p|u|m|b|a|g|s|d...
    Sets Wake-on-LAN options.  Not all devices support this.  The argument to this option is a string of characters specifying which options to
    enable.

    p   Wake on PHY activity
    u   Wake on unicast messages
    m   Wake on multicast messages
    b   Wake on broadcast messages
    a   Wake on ARP
    g   Wake on MagicPacket™
    s   Enable SecureOn™ password for MagicPacket™
    d   Disable (wake on nothing).  This option clears  all
        previous options.

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

8 participants