Deactivation of instance(s) - components continue (s)

[Cosmicbase]

• I confirm that this is an issue rather than a question.

Bug report

If I deactivate an instance in the WebGui, the component "hardware-recording" continues, for example.
This is bad because otherwise the USB 3.0 grabber will continue to run and use up resources.

Steps to reproduce

If I deactivate an instance in the WebGui or by remote command, the hardware-recording continues under components, for example.

What is expected?

Components must turn off first and then the instance itself.

What is actually happening?

Instance is switched off but components continue to run in the background.

System

Hyperion Server:

Build: (HEAD detached at pull/1210/merge) (GitHub-5b8b5ca5/cd473c78-1615394428)
Build time: Mar 10 2021 17:00:45
Git Remote: https://github.com/hyperion-project/hyperion.ng
Version: 2.0.0-alpha.9-PR#1210
UI Lang: auto (BrowserLang: de-DE)
UI Access: default
Avail Capt: dispmanx,v4l2,framebuffer,qt
Database: read/write
Hyperion Server OS:

Distribution: Raspbian GNU/Linux 10 (buster)
Architecture: arm
CPU Model: ARMv7 Processor rev 3 (v7l)
CPU Type: Raspberry Pi 4 Model B Rev 1.1
CPU Revision: b03111
CPU Hardware: BCM2711
Kernel: linux (5.10.17-v7l+ (WS: 32))
Qt Version: 5.7.1
Python Version: 3.5.3
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML

[Lord-Grey]

@Cosmicbase Given that the Grabbers are global objects and input for one to many instances, the grabber cannot be easily switched of when one instance is disabled.
A Hyperion instance is to drive an LED device. It is not the overall pipeline covering input and output processing.

[vena]

if the goal is conserving CPU when the grabber isn't "in use," it may be worth exploring an option to drop the frame rate and (maybe*) resolution of the grabber when signal is lost. i have done that with a hacky external python daemon using API subscriptions and updating the config, but updating the config that way doesn't seem like the best idea. in my testing, dropping the frame rate alone can cut CPU usage nearly by half, dropping resolution can cut it by half again. hyperion is still able to detect signal return immediately wherein i restore frame rate and resolution.

a built-in method, revealing an option to select a different frame rate and resolution for the grabber when signal detection is enabled, would be a nice addition.

* switching resolution seems to make my MS2109 HDMI->USB grabber flip out occasionally, but that's my grabber and i would just not use the resolution option in my case.

[Lord-Grey]

@Cosmicbase Would you mind testing with the latest version again, please?

I created two instances seeded by an USB V42L Grabber, then
a) Stopped the first one, Grabber works
b) Stopped the 2nd one too, Grabber stops

You need to disable an instance via the dashboard

with the PR #1535 you will be able to disable all Instances in one go...

[Cosmicbase]

@Lord-Grey I will test these and report to you.

[Lord-Grey]

Closing as no feedback was provided.