@sdetweil I’m going to go ahead and start over on with a clean build on bullseye. This one is still running on buster which may be part of the issue. I’ve got another Pi I can use and I’ll just use the config from this one and rebuild it. Thanks for the quick reply.

So after I ran the update script, magicmirror wouldn’t start.

This was in the log

[03.07.2023 08:40.46.643] [ERROR] 2023-07-03T08:40:46 <error> (node:17008) UnhandledPromiseRejectionWarning: Error: The module '/home/pi/MagicMirror/modules/MMM-Buttons/node_modules/epoll/build/Release/epoll.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 93. This version of Node.js requires
NODE_MODULE_VERSION 116. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:2:1822)
    at Module._extensions..node (node:internal/modules/cjs/loader:1354:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:2:1822)
    at Module.load (node:internal/modules/cjs/loader:1124:32)
    at Module._load (node:internal/modules/cjs/loader:965:12)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at Module.require (node:internal/modules/cjs/loader:1148:19)
    at require (node:internal/modules/cjs/helpers:110:18)
    at bindings (/home/pi/MagicMirror/modules/MMM-Buttons/node_modules/bindings/bindings.js:112:48)
    at /home/pi/MagicMirror/modules/MMM-Buttons/node_modules/epoll/epoll.js:7:31
    at Object.<anonymous> (/home/pi/MagicMirror/modules/MMM-Buttons/node_modules/epoll/epoll.js:15:3)
    at Module._compile (node:internal/modules/cjs/loader:1269:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1324:10)
    at Module.load (node:internal/modules/cjs/loader:1124:32)
    at Module._load (node:internal/modules/cjs/loader:965:12)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
(Use `electron --trace-warnings ...` to show where the warning was created) (/home/pi/MagicMirror/node:internal/process/warning:60 writeOut)
[03.07.2023 08:40.46.645] [ERROR] 2023-07-03T08:40:46 <error> (node:17008) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (/home/pi/MagicMirror/node:internal/process/warning:60 writeOut)
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open kms_swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:\$${ORIGIN}/dri:/usr/lib/dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:\$${ORIGIN}/dri:/usr/lib/dri)
failed to load swrast driver
Gdk-Message: 08:40:55.667: electron: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

I tried

npm rebuild

I tried

npm install

Wasn’t working.

An unhandled error occurred inside electron-rebuild
Could not detect abi for version 25.2.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

I saw a message

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: 'lru-cache@10.0.0',
npm WARN EBADENGINE   required: { node: '14 || >=16.14' },
npm WARN EBADENGINE   current: { node: 'v16.13.1', npm: '9.7.1' }
npm WARN EBADENGINE }

I thought it was saying that my node was just a bit out of date, so I made the mistake of running

nvm install node

and now I get this

node: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by node)

help?

@Cr4z33 Yes, the data that us returned is in a different format. There may be some overlap, but overall it’s outside my skill set.

@Cr4z33 It doesn’t look like the data comes back the same. Sorry.

@Cr4z33 PirateWeather was easy because it uses the same format as DarkSky. If Tomorrow.io does as well then theoretically it could be easy to add a config setting for the URL along with the existing API key setting.

With the end of DarkSky API, I’ve forked this and updated it to use PirateWeather. https://github.com/gonzonia/MMM-BMW-PW

All coding credit goes to @Mykle1 . I pretty much just changed the name and a URL. Pirateweather does not support languages though and that was removed.

@bugsounet THANK YOU! This saved me a lot of headaches. I went ahead and updated to 2.18 and got the exact error you reference in the exact same module. A quick search and I found your very helpful solution. Thank you for sharing.

I’m trying this out as a replacement for the default newsfeed. I’m having trouble styling it though. I’d like it to have a more transparent background and to make the font white. I can’t seem to make that happen.
For example- on the default newsfeed module I set the background with rgba(0, 0, 0, 0.2);

I can’t get that to apply to this one.

@sdetweil It’s interesting. I’m seeing this error now instead of the socket disconnected error. I’ve changed the DNS on the MM to not use the pihole (it’s using Google DNS).

I don’t know why I’m seeing this vs. the other error all of a sudden. I still think it’s hard to blame the network exclusively. I have other modules too that all run fine at the exact same time.

I’ve tried to figure out how to catch the error but I don’t think I can. From what I can tell it’s making the async call and then while waiting for a response it loses the connection for some reason. I’m not skilled enough to re-write try the async queue method referenced in the github post I linked to previously. I’m just hopeful someone who has the same problem might have the skills to fix it or at least catch it better so that the module doesn’t fail completely. (Meanwhile I’ll keep trying to identify what the problem is).

@sdetweil I do but I thought I’d switched the DNS on there to not use it. Apparently not. This new error was likely the result of the update to pihole v5 (need to figure that out separately). Thanks for pointing me in the right direction!

New error now that I’ve increased logging. Not sure it’s related but it does seem more specific.
Error: getaddrinfo EAI_AGAIN photoslibrary.googleapis.com
Which could be this. https://github.com/googleapis/google-api-nodejs-client/issues/761

Popping up at this line (I have a log entry directly before that shows up, and one after that doesn’t)

            		var response = await this.request(token, 'mediaItems:search', 'post', null, data)

@Sean thank you. As always I appreciate the efforts you’ve put in. Much of my posting has been throwing out ideas to see what might stick too. I’m not adept enough at js to tackle this myself but may try at some point. I’ve got it logging at almost a line by line level to see if there’s one call that has the problem. I actually got a whole new error today which was weird. I’ll keep posting as I discover anything but please don’t think I’m trying to get you to do something, it’s more for documentation of the problem in hopes that someone can fix it!

@cowboysdude said in MMM-GooglePhotos:

He added logging and in there it should tell you why it’s failing…

Yes. This is the error and I appreciate all @Sean has done. However, whatever is causing the error below isn’t something I can identify/control/fix. There are no network issues anywhere else on my network except this single module. At least once a day I need to manually intervene to get it started again.

 Error: Client network socket disconnected before secure TLS connection was established (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)

@cowboysdude The URLs only last for an hour. That’s why it re-indexes and updates after 50 min. The issue @kykzzang and I are having is that sometimes during indexing there’s a network issue and the indexing doesn’t complete. When that happens the URLs don’t get updated and the module tries using the old URLs resulting in the the failed image loading.

@Sean Okay. I think I’m understanding the behavior a little more. It ran yesterday for over 12 hours. When it failed, it happened on indexing, then a single image was loaded successfully. After that all images failed and the module never tried refreshing the token or indexing again.

I don’t know what the cause of the network socket disconnected error is, but is there any way for the module to recover?

If it recovered even in another 50 min when it should do another scan, I think that’s reasonable. The problem is that the error is fatal to the scanning process and all the URLs are bad after the 60 min lifespan. The module never restarts the scanning after the initial failure.

@Sean So I had over 24 hours with it working. Swapped back to the original file and it errored out within 2 hours. Swapped back to new file and again errored in 2 hours. I don’t get it. I was mistaken with what I changed, I changed the getImage call to a pageSize of 25. This made indexing take longer. It always returns the TLS error when indexing. I have it looking at two albums. One is big with 937 images. The other is only 129. When the error happens it is always while indexing the first one. Is the large album the problem?

[2020-05-02 21:35:51.841] [LOG]    2020-05-02T21:35:51 <log> [GPHOTOS] Start Album scanning (/home/pi/MagicMirror/modules/MMM-GooglePhotos/node_helper.js:44 Class.log)
[2020-05-02 21:35:51.845] [LOG]    2020-05-02T21:35:51 <log> [GPHOTOS:AUTH] Token is alive. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:20 Auth.log)
[2020-05-02 21:35:51.848] [LOG]    2020-05-02T21:35:51 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:35:53.427] [LOG]    2020-05-02T21:35:53 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:35:55.358] [LOG]    2020-05-02T21:35:55 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:35:56.996] [LOG]    2020-05-02T21:35:56 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:35:58.431] [LOG]    2020-05-02T21:35:58 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:35:59.769] [LOG]    2020-05-02T21:35:59 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:36:01.544] [LOG]    2020-05-02T21:36:01 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-05-02 21:36:16.288] [LOG]    2020-05-02T21:36:16 <log> [GPHOTOS:CORE] Error: Client network socket disconnected before secure TLS connection was established (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)

@Sean Okay. Thanks. As a stab in the dark I changed the pageSize in the getAlbum call to 25. It’s been running now for 14 hours without an error. If it’s still good in the morning I’ll restore the old version and see if the error comes back. I don’t remember what led me down that path but something this morning made me think to give it a try.

@Sean 403 is a “forbidden” status. Is it possible to catch that status being returned and then go back to refreshing the token and starting the process over from there?

@Sean Sadly, it doesn’t look like that’s it. Everything ran great for 12 hours, than quit again. Restarted this morning and it lasted an hour or two. The problem always appears arround indexing.

[2020-04-30 08:56:17.785] [LOG]    2020-04-30T08:56:17 <log> [GPHOTOS] Start Album scanning (/home/pi/MagicMirror/modules/MMM-GooglePhotos/node_helper.js:44 Class.log)
[2020-04-30 08:56:17.789] [LOG]    2020-04-30T08:56:17 <log> [GPHOTOS:AUTH] Token is alive. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:20 Auth.log)
[2020-04-30 08:56:17.791] [LOG]    2020-04-30T08:56:17 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
REPEATS....
[2020-04-30 08:56:55.332] [LOG]    2020-04-30T08:56:55 <log> [GPHOTOS:CORE] Indexing photos now. (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-04-30 08:57:17.685] [LOG]    2020-04-30T08:57:17 <log> [GPHOTOS:CORE] Error: Client network socket disconnected before secure TLS connection was established (/home/pi/MagicMirror/modules/MMM-GooglePhotos/GPhotos.js:124 GPhotos.log)
[2020-04-30 08:57:18.712] [LOG]    2020-04-30T08:57:18 <log> [GPHOTOS] Image loaded: https://lh3.googleusercontent.com/XXXXXX (/home/pi/MagicMirror/modules/MMM-GooglePhotos/node_helper.js:44 Class.log)
[2020-04-30 08:59:18.130] [LOG]    2020-04-30T08:59:18 <log> [GPHOTOS] Image loading fails. Check your network.: https://lh3.googleusercontent.com/XXXXXXXX(/home/pi/MagicMirror/modules/MMM-GooglePhotos/node_helper.js:44 Class.log)

I’m determined to figure this out though.

@Sean I’ve got a theory. I don’t know enough about how it’s all working to be sure, but I’m testing it a little. I noticed in the logs that the error seemed to coincide with something the CalendarExt2 module was doing. Since they’re both connecting to Google, I thought, perhaps there’s something happening there. I’ve disabled the CalendarExt2 module and haven’t had a problem. I’m going to see how it all runs for today and then turn the module back on to see if the problem returns.