@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]

@sdetweil

@sdetweil

The docker stack is running on magicmirroros (https://gitlab.com/khassel/magicmirroros). Installed in May’24 from the provided image.

Saw the new release was recently out. Not sure if failed before or after that.
Noted it had failed 1pm US central time.
Updated the OS and containers about 2pm US central time.

Looking https://gitlab.com/khassel/magicmirror/-/pipelines - I think the containers might have been updated since the new release.

scottwalsh@calendar:/opt/mm/run/includes $ 
scottwalsh@calendar:/opt/mm/run/includes $ cat watchtower.yaml 
services:
  watchtower:
    privileged: true
    image: ${WATCHTOWER_IMAGE}
    container_name: watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    # --interval 300 --> poll interval in seconds
    # --cleanup --> for auto image pruning
    command: --interval ${MM_WATCHTOWER_INTERVAL} ${MM_WATCHTOWER_CLEANUP}
    restart: always
scottwalsh@calendar:/opt/mm/run/includes $

Running magicmirroros which uses Karsten’s docker implementation.

This morning found mm blank, and the mm container had sigfault errors connecting to the screen (didn’t collect logs). As been at last six months since last updated, updated the os (apt-get update/upgrade), containers, and rebooted.

Everything looks to be running fine outwardly, however noted a few errors in the container logs.
And the watchtower log is just in a loop restating.

Extracts below.

scottwalsh@calendar:/opt/mm/run $ docker logs mm
[2026-01-02 07:59:07.394] [LOG]   [app] Server started ... 
[2026-01-02 07:59:07.397] [LOG]   [node_helper] Connecting socket for: MMM-mmpm 
[2026-01-02 07:59:07.399] [LOG]   [node_helper] Starting module helper: MMM-mmpm 
[2026-01-02 07:59:07.401] [LOG]   [node_helper] Connecting socket for: calendar 
[2026-01-02 07:59:07.402] [LOG]   [calendar] Starting node helper for: calendar 
[2026-01-02 07:59:07.404] [LOG]   [node_helper] Connecting socket for: MMM-AVStock 
[2026-01-02 07:59:07.406] [LOG]   [node_helper] Connecting socket for: MMM-anotherNewsFeed 
[2026-01-02 07:59:07.408] [LOG]   [MMM-anotherNewsFeed] Starting node helper for: MMM-anotherNewsFeed 
[2026-01-02 07:59:07.409] [LOG]   [node_helper] Connecting socket for: updatenotification 
[2026-01-02 07:59:07.411] [LOG]   [node_helper] Starting module helper: updatenotification 
[2026-01-02 07:59:07.412] [LOG]   [app] Sockets connected & modules started ... 
[21:0101/185908.239072: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 07:59:08.641] [LOG]   [electron] Launching application. 
[21:0101/185909.015470:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
[21:0101/185909.016371: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:0101/185909.016913: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:0101/185909.017979: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:0101/185909.018861: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:0101/185909.023819: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 07:59:12.566] [INFO]  [utils] 


scottwalsh@calendar:/opt/mm/run $ docker logs watchtower
time="2026-01-01T18:58:38Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:58:38Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:58:43Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:58:43Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:58:46Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:58:46Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:58:50Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:58:50Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:58:54Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:58:54Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:58:58Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:58:58Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:59:04Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:59:04Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:59:13Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:59:13Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:59:27Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:59:27Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
time="2026-01-01T18:59:55Z" level=error msg="Error response from daemon: client version 1.25 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"
time="2026-01-01T18:59:55Z" level=info msg="Waiting for the notification goroutine to finish" notify=no
scottwalsh@calendar:/opt/mm/run $

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).