Read the statement by Michael Teeuw here.
MMM-GooglePhotos
-
@gonzonia said in MMM-GooglePhotos:
@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)It’s disconnecting before the proper connection can be made… so it sounds like a Google issue.
-
Hello,
I’m a newbie on Magic Mirror, so please, be indulgent :)I’ve setup magic mirror as a server only on my NUC (via Docker) and I’ve installed npm module MMM-GooglePhotos on it.
I can access MM, and see all basic modules, browsing to the server and port configured in docker. So no problems there.I’m blocked though, on the installation (authorization part) of MMM-GooglePhotos module.
I’ve created all credentials on google, however, being a server only installation of magic mirror, I cannot complete the OAUTH token generation as advised in the docs, as via console there is no way to open a “browser” and access google consent screen.Is there any other way, maybe using a generic google API in the config, to authorize without going through consent screen?
Maybe doing the consent somewhere else (accessing an URL?) and then copy (and/or craft) the token somehow?Thank you for your time and help!
P.S.
Apologies if this is not the best place to post this message, so please advise if that’s the case. -
As I’ve said in another post, I couldn’t maintain this module anymore.
However, yesterday night, suddenly I got an idea of what happened. (Not tested, and… sorry, I couldn’t test)
Most of MM modules and MM itself are using the same port to communicate internally and externally. I suspect some modules(and even inside logics in a module) were racing to use the port. They had opened and closed the port by their own schedule, which could make this symptom. Connection with Google Server often needs some long time probably.
The solution might be to use a different port not to race. and make the connections not to happen asynchronously. For the performance, I usually used asynchronous attempting to communicate with Google Server, It might make worse that issue.
Well, some modification of source might be needed, but as I’ve said (again), I couldn’t.Anyway, this guess is not confirmed by the test, just an idea.
If someone could get an inspiration, I hope this guess could be a help. -
@Sean makes perfect sense!! I guessed that was Google … I could only offer that much help as I don’t have time to really look at it either.
Thank you for the response and someone with more time could take a peek at it.
-
@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!
-
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/761Popping 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) -
@gonzonia said in MMM-GooglePhotos:
getaddrinfo EAI_AGAIN
that means your network failed… are u using a pihole for connection security?
seen lots of failures thru pihole…
-
@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!
-
@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).
-
@gonzonia i don’t think the referenced issue is the problem, but there is a bunch of work needed to improve error recovery. I don’t KNOW for sure what the problem IS, but looking at the code there is no recovery from it.
