Trixie/node v24 - timeouts on request to the internet

sdetweil

@Mr.Sponti our code uses a 30 second timeout, but it can be changed by setting an environment variable , here 45 seconds

export mmFetchTimeout=45000
In the script used to launch MagicMirror

See the doc here
https://docs.magicmirror.builders/configuration/introduction.html#advanced-configuration-and-frequently-asked-how-to-configure-examples
I submitted a change to fix the doc which has two defaults specified

But I think you need to fix you network

Mr.Sponti

Hi Sam, thank you for your fast response and support!
I’ve played with the mmFetchTimout parameter without success. As I didn’t had any network issues with Bullseye, MM v2.26.0 and node v20.18.0, I downgraded node to v22.18 and the network issues are gone.
But I’m now faced with another big issue under Trixie. If I schedule modules using graphic functions like vlc, the CPU load increase dramatically. There is one electron process with parameterer –type=zygote consuming the whole CPU capacity.

From copilot I got the answer: High CPU usage from electron --type=zygote is usually tied to Chromium’s zygote process, which forks renderer processes.

Do you have any idea how to get this problem under control?

sdetweil

@Mr.Sponti thanks for the feedback, hadn’t expected node to be the problem .

As for the vlc perf issue , not sure . There have been vlc issues in electron before.

You might try the next release develop branch
See https://forum.magicmirror.builders/topic/14327/testing-new-fixes-or-solving-current-problems-with-next-release-code

A quick way without touching your existing setup use my backup script to save the module list , config and css
Rename the MagicMirror folder
git clone the repo, checkout the develop branch
Oh it needs node 24 (use n or nvm to switch version)
npm install
Run the restore script to put the modules, config and css in the new MagicMirror folder

https://github.com/sdetweil/MagicMirror-backup-restore

Mr.Sponti

After further investigations I found the reason for the heavy CPU load. Originator for this behaviour ist the parameter “ELECTRON_ENABLE_GPU=1”. If this parameter is undefined my CPU load is as expected.

I’ve also had a deeper look to run the “VLC video player” with RTSP streams from my cameras. Using the following command line parameter leads in my environment to best results:

var opts = { detached: false, env: environ }		
var args = ["-I dummy",
   "-q",
   "--zoom=" + this.window.zoom.toString(),
   "--video-x=" + this.window.x.toString(),		//	x,y-positioning does't work
   "--video-y=" + this.window.y.toString(),		//	...
   "--no-audio",
   "--video-on-top",
   "--no-video-deco",
   "--no-osd",
   "--no-video-title-show",
   "--network-caching=1000",
   "--rtsp-tcp",
   `${this.streams[stream].url}`
]
//console.log(playerPath + this.player, args)
this.streaming.player = spawn(playerPath + this.player, args, opts)

sdetweil

@Mr.Sponti do you have the gpu hardware enabled?
If not then I think electron tries to emulate it, probably w the vlc content