Read the statement by Michael Teeuw here.
MMM-GooglePhotos
-
@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.
-
correct, the code then fails, the module sends the helper a message
case 'IMAGE_LOAD_FAIL': this.log("Image loading fails. Check your network.:", payload) break
and the helper logs it, but never does anything after that
so, now the module is waiting for another image,case 'UPLOAD': this.upload(payload) break
but the helper doesn’t know
-
@sdetweil
Nothing can be dine after image loading fails. Even connected again, couldn’t be recognized. It is just kind logging.
I’m not sure what could be possible to do for this kind of network issue by module itself. -
Hi @Sean , thanks a lot for your time and effort on creating this module, I was searching for something similar for a long time already. From time to time, I’m getting several Forbidden 403 responses from the requests to load new pictures, this gives the impression that the pictures are stuck. Do you have an idea of what might be causing that?
-
@RoggerFabri
All those kinds of errors (403, 500, …) means network/server errors. Nothing could do in client(module) itself. Only thing would be just waiting(stuck) problem solved by network/server. -
@RoggerFabri - I don’t know if this is relevant, but I know Amazon AWS bulk storage returns 403 errors if you get the URL wrong. I’m not sure if their security model is so granular that files have to be authorized independently or if the wrong URL attempts to serve up the directory index and that file is locked out. And I have no idea if Google uses the same technique.
Either way, I would check the request to make sure it is pointing to a valid asset.
-
@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?
-
@gonzonia
There could be possibility “dead url after it’s lifetime”(60 minutes) but to avoid it, photos working urls would be rescanned and refreshed per 50mins.
Of course, if there be network error to prevent resurrection, it will not work. That is not the token issue. -
This post is deleted! -
@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.