@dangerousden AWESOME!!! thanks for the great post… one thing from above, when posting config content or log info, please use the code block wrapper past the text, blank line above and below, select the text you just pasted, hit the </> button to use the wrapper…

@BKeyport yes, if I discover you are not on the master branch, I move you to master, then update from there. For exactly this situation. Trying a specific fix or all of develop branch.

@KristjanESPERANTO thanks for the great info

@sdetweil , @kristjanesperanto , I’ve decided to resolve it by myself - with Sam’s hint/advice/helper-file. It seems to work - will double check my cache size in a few days. Thanks again for your great support. Migration is a bigger task and wihout any need currently too much - even cache-growth wouldn’t change this. never touch a running system :-) Warm regards, Ralf

@tommyk glad you got it working As for remote control , open another topic. I’m sure someone can help

@nobbie35 scripts are here, mentioned in MagicMirror install doc https://github.com/sdetweil/MagicMirror_scripts Backup/restore should work if you can run it from the nas command line (it’s all bash) and if git is there you could push to a repo of yours https://github.com/sdetweil/MagicMirror-backup-restore This takes optional parm’s for the folder name of MagicMirror and the place to put the backup

@smegbadger you would have to load the develop branch of MagicMirror, as we don’t distribute less than the full package… see this link https://forum.magicmirror.builders/topic/14327/testing-new-fixes-or-solving-current-problems-with-next-release-code

@Richard238 generally I recommend sticking with the one that comes w the nodejs version.

@RonR Thanks for the positive feedback. I found it amusing that you thanked Sam first, since he provides most of the support here — something for which, honestly, I often lack the time and patience… The problem itself seemed familiar to me; I just had to track down the corresponding issue.

@heath1066 awesome.

@Phantomkommander this fix is now in 2.36 released today

@TiLow awesome! As moderator here, I think my job is to help users make and keep their mirrors running. Watch for trouble and find ways to resolve it. Your clear description of the problem helped identify a good resolution. I didn’t do any of the work. Just connected the dots.

@Lmagenis ok, understood We changed npm start to use the Wayland compositor, instead of x11 because the pi os has that as default now If you used my install script and selected pm2, then my startup script (mm.sh) detects which compositor is running, and issues the appropriate start command

@Drunkenkun yes, calendarweek does need the config, it fetches the events itself too

@angeliKITTYx awesome. Thanks for the feedback

@sdetweil many thanks for your help once again sam!

@MarNog one thing about the ext3 family of modules. They get the events from the default calendar module. But the events are broadcast by url separately. Some will take longer than others. Ext3 doesn’t want to flash the screen every time it receives a block of events. It doesn’t know when the events will come. So, it has its own refreshInterval time (10 mins default), then it draws whatever it has, and then waits again But, you don’t want to wait 10 minutes for the first display , so it has a second timer waitFetch:5000, 5 second wait before drawing any events If the events arrive after 5 seconds, they dont get displayed til refreshInterval time. So, you can adjust those two to improve your viewing experience Note that longer waitFetch means more time after start before any events are displayed If you use pm2 to launch MagicMirror, it captures the log messages about startup and events being broadcast. You could examine those time stamps to determine how long each cal Might take, and use that as a guide to waitFetch time The longer waitFetch means no events are displayed after startup til waitFetch expires

@KristjanESPERANTO Finally got time to fix things up and move forward (Complete reinstall, honestly) Everything is working as I desire now.

@sdetweil I switched back to X11 in raspi-config, rebooted and added the parameter DISPLAY=:0 npm run start:x11 That works! :-) As it is quite after midnight here, I’ll do these tests with wayland tomorrow and respond here. So far, thank you a lot.

@Hepkat awesome. Thx for the feedback