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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 | Shutdown after [Time] idle #1970

Open
DarthBlair opened this issue Feb 12, 2023 · 6 comments 路 May be fixed by #2332
Open

馃殌 | Shutdown after [Time] idle #1970

DarthBlair opened this issue Feb 12, 2023 · 6 comments 路 May be fixed by #2332
Labels
enhancement future3 Relates to future3 development
Milestone

Comments

@DarthBlair
Copy link

Feature Description

If the Box wasn't user for a while, the Raspberry shuts down.

What functionality would you like to see in your phoniebox?

Enable/Disable Option for idle Shutdown
Configurable Timer for Shutdown

How do you envision the feature to work from a users perspective?

If the Option is Enable an the box wasn't user f眉r the configured Time it will shut down the pi to save power.

@PsychoD
Copy link

PsychoD commented Feb 12, 2023

+1
I really miss this functionality in future3...

@s-martin s-martin added the future3 Relates to future3 development label Feb 12, 2023
@votti
Copy link

votti commented Mar 1, 2023

I also would appreciate this a lot.

# The idle Timer does work in a little sneaky way
# Idle is when there are no calls through the plugin module
# Ahh, but also when music is playing this is not idle...
# Use setattr to replace plugin._call with a plugin._call that saves last access time
# Three options:
# (a) whenever a call happens -> restart timer
# (b) save last call access time -> when timer times out, check that time with timer and restart if necessary with
# (c) Sniffer on Publisher -> If nothing happens for ages
# Most efficient would be a measure the time in the Publisher and use a callback
# (d) PubSub starts a Timer with target=shutdown. Timer can reset time via function call
# delta time

seems to indicate that someone has already thought about this before. Does a POC implementation of any of the options already exist?

@votti
Copy link

votti commented Mar 1, 2023

I was wondering: are the rpc calls also published under a topic in the message cue?
As far as I can tell this is not the case, but would be useful.

To me having tracking:

  • time since the playerstatus has last been not paused -> could be derived by listening to the playerstatus topic
  • time since last rpc call -> listing to the rpc call topic -> additional filtering to ignore some call may be necessary

Together would enable to determine the idle time and decide for a shutdown

@pabera
Copy link
Collaborator

pabera commented Mar 16, 2023

I think the functionality is already there.. and you hinted the right spot in the code. The only thing missing is a frontend integration.

You could try to execute the time command from the RPC CLI.

@s-martin s-martin linked a pull request Apr 15, 2024 that will close this issue
@s-martin s-martin linked a pull request Apr 15, 2024 that will close this issue
@hoffie
Copy link
Contributor

hoffie commented Apr 15, 2024

#2332 has a working attempt at implementing an idle shutdown timer.

@votti

time since the playerstatus has last been not paused -> could be derived by listening to the playerstatus topic

I have implemented that (a bit more generalized: any change in player status is considered activity).

time since last rpc call -> listing to the rpc call topic -> additional filtering to ignore some call may be necessary

I have not implemented that part. Instead, I chose to monitor relevant file changes (configs & audio content). That should capture any administration tasks such as adding new cards, changing configs and updating audio content.
In addition, I have added tracking for active SSH sessions (mostly aimed at developers or builders who are in the process of configuring/updating and don't want to be caught by an unexpected shutdown).
Do you think not implementing the rpc logic misses anything relevant? I couldn't think of anything and was worried about false positives instead (i.e. if any component/extension would use some kind of polling via rpc calls that would be considered activity, without knowing if that makes sense at all).

@pabera

I think the functionality is already there.. and you hinted the right spot in the code. The only thing missing is a frontend integration.

You could try to execute the time command from the RPC CLI.

I haven't found that code though. Maybe I have missed it? :)

hoffie added a commit to hoffie/RPi-Jukebox-RFID that referenced this issue Apr 15, 2024
This adds an optional idle shutdown timer which can be enabled
via timers.idle_shutdown.timeout_sec in the jukebox.yaml config.

The system will shut down after the given number of seconds if no
activity has been detected during that time. Activity is defined as:
- music playing
- active SSH sessions
- changes in configs or audio content.

Fixes: MiczFlor#1970
@pabera
Copy link
Collaborator

pabera commented Apr 15, 2024

@votti

time since last rpc call -> listing to the rpc call topic -> additional filtering to ignore some call may be necessary

I'd be interested in some use cases. A few calls won't interfere with MPD, but ultimately it boils down to either "play" or "don't play". I think with the current implementation, a high percentage of use cases are covered. Thoughts?

@hoffie
I updated my comment. I believe I confused the Idle Timer with Sleep Timer :-)

@pabera pabera added this to the v3.6 milestone Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement future3 Relates to future3 development
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants