MMM-GooglePhotos

A Former User

@gonzonia
It makes some sense. By racing to use the same connection, there could be some conflicts. Hmmmm…

gonzonia

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

sdetweil

@gonzonia

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

A Former User

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

RoggerFabri

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?

A Former User

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

bhepler

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

gonzonia

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

A Former User

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

orayoflighto

This post is deleted!