fixed now, you can restart the pi (it will need some time to pull the new image before working) or cd /opt/mm/run docker compose pull docker compose up -d

Family calendar, went for a custom framed screen as opposed to a mirror surface, may at a mirror surface later. [image: 1739821121311-img_0811-1.jpeg] 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