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.

@ArnoldoB

The fork you created doesn’t resolve it, also needed to use the new function to set the user agent.

Was able to build on the branch you created for v3 support and get it working.

In summary:
Forked your branch
Upgraded yahoo finance to the latest version (3.11.2).
Update MMM-AVStock to use the new user agent function (^3.11.2)

Looks like all fixed.

Will give it a day or two and it looks fine will submit a pull request.

@ArnoldoB Noted the screenshot seems to be a broken file on GitHub (and in the post here).

@ArnoldoB
Submitted a pull request to the upstream.

@ArnoldoB

Was looking at your roadmap, a suggestion:
In addition to syncing with brokers, you could also look at portfolio tracking products like https://www.sharesight.com/nz/

@wyovino

The fix is that the module needs to be running yahoo finance 3.11.0 or higher and use the new feature to set the user agent.

I’ve a fork of MMM-AVStock that I think have fixed this evening and am testing. https://github.com/scottwalshnz/MMM-AVStock

@ArnoldoB

The fork you created doesn’t resolve it, also needed to use the new function to set the user agent.

Was able to build on the branch you created for v3 support and get it working.

In summary:
Forked your branch
Upgraded yahoo finance to the latest version (3.11.2).
Update MMM-AVStock to use the new user agent function (^3.11.2)

Looks like all fixed.

Will give it a day or two and it looks fine will submit a pull request.

@ArnoldoB
Is it still working? I see your pull request is before the version of yahoofinance that made the user agent changes a couple of days ago.

@sdetweil
On the MMM-AVStock GitHub page? I don’t find an issue there that seemed to match.

Have found issue report for the yahoo-finance2 api, and that is resolved in the latest version by being able to set the user agent. However, looks like yf2 would need upgraded in MMM-AVStock, and then set the user agent.

https://github.com/gadicc/yahoo-finance2/issues/977

I’m using the MMM-AVStock module, and it stopped loading quotes a couple of days ago and investigated it today.

It looks like the module might be no longer compatible with yahoo finance?

Found in the mm container logs the following for every stock I have configured (using mm containerised from the magic mirror os install).

[2026-01-06 10:42:02.943] [ERROR] [MMM-AVStock] Error in loading quote data for Symbol ^NZ50

Added to the try/catch that pulls the stock the following so can see the actual error:

console.error(error);

The stack trace logged:

[2026-01-06 10:42:02.943] [ERROR] [MMM-AVStock] Error in loading quote data for Symbol ^NZ50 
[2026-01-06 10:42:02.945] [ERROR] [MMM-AVStock] SyntaxError: Unexpected token 'T', "Too Many Requests
" is not valid JSON
    at JSON.parse (<anonymous>)
    at parseJSONFromBytes (node:internal/deps/undici/undici:5852:19)
    at successSteps (node:internal/deps/undici/undici:5833:27)
    at fullyReadBody (node:internal/deps/undici/undici:4725:9)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async consumeBody (node:internal/deps/undici/undici:5842:7)

I did have a play with adding a 15 sec pause for each pull of a stock in case some simple rate limiting would resolve it, but did not resolve the issue.

Have noted the module uses an older version of yahoo-finance2, so wondering if that needs upgraded - gets beyond my basic js skills.

@karsten13 said in Docker Watchtower container restarting and mm container errors after upgrade:

I found a good documented PR in another project which explains the dbus errors in detail.

Thanks for providing the link, interesting background.

@karsten13

Thank you for that. The Watchtower seems to be running fine now.

Did you have any thoughts on these errors that appear in the mm container? Seems to be running fine.

[Extract]

scottwalsh@calendar:/opt/mm/run $ docker logs mm
[2026-01-02 14:09:18.082] [LOG]   [app] All module helpers loaded. 
[2026-01-02 14:09:18.105] [LOG]   [server] Starting server on port 8080 ...  
[2026-01-02 14:09:18.113] [WARN]  [server] You're using a full whitelist configuration to allow for all IPs 
[2026-01-02 14:09:18.226] [LOG]   [app] Server started ... 
[2026-01-02 14:09:18.229] [LOG]   [node_helper] Connecting socket for: MMM-mmpm 
[2026-01-02 14:09:18.231] [LOG]   [node_helper] Starting module helper: MMM-mmpm 
[2026-01-02 14:09:18.233] [LOG]   [node_helper] Connecting socket for: calendar 
[2026-01-02 14:09:18.235] [LOG]   [calendar] Starting node helper for: calendar 
[2026-01-02 14:09:18.236] [LOG]   [node_helper] Connecting socket for: MMM-AVStock 
[2026-01-02 14:09:18.239] [LOG]   [node_helper] Connecting socket for: MMM-anotherNewsFeed 
[2026-01-02 14:09:18.240] [LOG]   [MMM-anotherNewsFeed] Starting node helper for: MMM-anotherNewsFeed 
[2026-01-02 14:09:18.242] [LOG]   [node_helper] Connecting socket for: updatenotification 
[2026-01-02 14:09:18.243] [LOG]   [node_helper] Starting module helper: updatenotification 
[2026-01-02 14:09:18.245] [LOG]   [app] Sockets connected & modules started ... 
[21:0102/010919.030995:ERROR:dbus/bus.cc:408] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[2026-01-02 14:09:19.430] [LOG]   [electron] Launching application. 
[21:0102/010919.848714:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
[21:0102/010919.850527:ERROR:dbus/bus.cc:408] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[21:0102/010919.852228:ERROR:dbus/bus.cc:408] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[21:0102/010919.852910:ERROR:dbus/bus.cc:408] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[21:0102/010919.860171:ERROR:dbus/bus.cc:408] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[21:0102/010919.860444:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
[2026-01-02 14:09:23.059] [INFO]  [utils]