Family calendar, went for a custom framed screen as opposed to a mirror surface, may at a mirror surface later.

Hardware
Hardware is a Pi Zero 2W with a cheap portable monitor (Firebat).

MM Configuration
Modules is a simple set up of a CalendarExt3 with the default weather and time pulling five ics calendars from google (a calendar for each person plus a shared one).

OS
Used the MagicMirrorOS for the build, had some intermittent issues as noted in a troubleshooting thread that @KARSTEN13 and @SDETWEIL gave some good pointers on so could put in a workaround.

Server Side
On the google side, have written two Google Scripts to transform the calendar entries a little.

Script 1
Events are prefixed by “[CalendarName]” so clear which calendar the event belongs to without colour coding.

Script 2
Also a script that takes a calendar and copies the events to another, optionally padding the times for travel times (hardcoded) and rewriting the the title so that the original time is included. This allows me to consolidate several calendars into one.
End result is (for example) my calendar for display (SW), has copied into two ics feeds, one of any gym classes I have booked (padded with travel time) and one from Tripit unpadded. Similar with my wife’s calendar with her gym bookings.

As an update, based on the pointers from @KARSTEN13 and @SDETWEIL, have a workaround.

Had three issues going on.

1:
I found that on a graceful reboot (shutdown -r now) that it would generally start fine, but not on an ungraceful reboot (power cycle the machine).

Looks like when it was ungraceful reboot, the labwc container would show with uptime of (for example) five hours when ‘docker ps’, even though the machine was rebooted 20min ago after ‘docker compose up’ was executed by install.sh. Whereas the magicmirror container would have recently started.

I assume kind of lock file confusing things?

Workaround was to change the first ‘docker compose up’ install.sh to ‘docker compose up -d --force-recreate’

2:
I’d also included a pause and --force-recreate at the end of the install.sh and noted it was never executing as per @KARSTEN13’s suggestion.
Looked like the install.sh script was hanging at docker compose pull.
Commented that out.

3:
Lastly, the initial ‘docker compose up -d --force-recreate’ in install.sh would still fail often with the mm container restarting with logs as per the original post.

With a 7 min pause and then second ‘docker compose up -d --force-recreate’ it seems to start the second time well (3min wasn’t enough, 5min was better, 7min seems to work).

Workaround is a bit on the slow side, at some point will see if can refactor it a bit so that a pull for updates occurs.

Extract of resulting install.sh below.

_info "--> Pulling docker images and starting magicmirror"
# need sudo for docker here if docker was installed with this script

# use up so mm can start if there are already local images
_info "--> Pre Start Pause for 2min"
sleep 120

_info "--> Start and recreate"
$_sudo docker compose up -d --force-recreate

#_info "--> Pull Pause for 1 min"
#sleep 60
# pull new images
#_info "--> Image Pull"
#$_sudo docker compose pull

#_info "--> Restart Pause for 1 min"
#sleep 60
# restart (only if new images pulled)
#_info "--> Restart stopped"
#$_sudo docker compose up -d

_info "--> Final Pause for 7 min"
sleep 720

_info "--> Final  start and recreate"
$_sudo docker compose up -d --force-recreate

if [[ "$_sudo" == "sudo" ]]; then
  _info "--> Reboot needed, starting in 120 sec. (use ctrl-c to skip)"
  sleep 120
  sudo reboot now
fi

# cleanup
$_sudo docker image prune -f

Moving to 64bit looks like might have helped. Up for 18 hours since rebuilding so far with my full calendar configuration.

Observation - took about 30 min to boot through displaying the calendar. Load average getting up to 20.0+ during boot, assume swapping a lot via the slow SD card interface. So although looks more stable, much slower performance.

Installed the pi 4 today.

Was getting up to 4 days on the 02W without it crashing, so will need to give it a week to know for sure.

Installed the pi 4 today.

Was getting up to 4 days on the 02W without it crashing, so will need to give it a week to know for sure.

Thanks for the tips, will take a look tomorrow to see how would do it via CSS.

Why would you recommend doing it via CSS? Turning the headers on and off as a config option feel more intuitive to me compared to using CSS to surpress them.

Although moving to 64 bit made it more stable, still found it was going blank after a few days requiring the mm container restarted.

Think the Zero 2W was too under powered for what I was trying to do. So have upgraded to a Pi 4.

I have two instances of the module, and I only want to hide the header on one instance. If I use CSS, wouldn’t it hide it for both?

I use the MMM-CalendarExt3 module, and decided for my configuration wanted to display it without the header (in week view).

Made the following modifications to make it into an option to turn the header on and off.

Sharing it here as haven’t looking into how to contribute via git…

--- MMM-CalendarExt3.js.org	2025-08-09 22:19:40.792525741 +1200
+++ MMM-CalendarExt3.js	2025-08-09 22:22:25.620897641 +1200
@@ -82,7 +82,7 @@
     skipDuplicated: true,
     monthIndex: 0,
     referenceDate: null,
-
+    showHeader: true, 
     customHeader: false // true or function
   },
 
@@ -755,7 +755,7 @@
       config: options,
       range: [boc, eoc]
     })
-    makeDayHeaderDom(dom, options, { boc, eoc })
+    if (options.showHeader) makeDayHeaderDom(dom, options, { boc, eoc })
     makeWeekGridDom(dom, options, targetEvents, { boc, eoc })
     if (options.displayLegend) displayLegend(dom, targetEvents, options)
     if (options.customHeader) customHeaderDom(dom, options, { boc, eoc })

Moving to 64bit looks like might have helped. Up for 18 hours since rebuilding so far with my full calendar configuration.

Observation - took about 30 min to boot through displaying the calendar. Load average getting up to 20.0+ during boot, assume swapping a lot via the slow SD card interface. So although looks more stable, much slower performance.

@sdetweil said in MM Screen goes blank 5-20min after starting (was stable on 2.31) - Pi Zero 2W running MagicMirrorOS:

sdetweil
3 minutes ago

@karsten13 he should examine use and adjust as required…

As @karsten13 noted, defaults to 1024 on a 2W (have done first boot post imaging). Will give it a go at 2048, likely a bit oversized.

@sdetweil said in MM Screen goes blank 5-20min after starting (was stable on 2.31) - Pi Zero 2W running MagicMirrorOS:

Away
sdetweil
3 minutes ago

@scottwalsh the 64bit version takes about 500m more memory than the 32 bit version…

Thanks for the tip, what’d you recommend as a min swap size? Will just try it off the SD card to start (as don’t have a USD at hand).

@karsten13 said in MM Screen goes blank 5-20min after starting (was stable on 2.31) - Pi Zero 2W running MagicMirrorOS:

You did not write which OS you are using, 32-bit or 64-bit. The 32-bit is more resource-saving

Hadn’t checked, until now. Have been using the 32-bit version.
Will reimage with the 64-bit version and see if it is more stable.

Did note the following error from the labwc container about four hours after starting it in the above example errors, so suspecting is part of it.

So I guess how can I troubleshoot/avoid this event.
And/or have the mm container reconnect after this occurs.

wlr-randr errors "failed to connect to display" so killing container.