Standard module Calendar hangs on events

Laz

@sdetweil Good afternoon!
I did not succeed in doing everything on your advice.
But I noticed that the blue calendar had not been updated for several days. And I looked at the log file.
It shows that until April 2, two calendars are being updated to 20.56.41. And after 21.01.28, only one calendar began to be updated. And so it was until I overloaded the mirror today.
I attach screenshots from the log file.

sdetweil

@Laz thanks. that’s the good info. how about the error log? I’m pretty sure there was a timeout error, and once errored, it never recovers.

but you should see the timeout error reported on the error log

Laz

@sdetweil

Good afternoon!
I couldn’t find any calendar related errors.
I can’t insert a txt file here. Changing the extension to a picture also does not go away.

sdetweil

@Laz pic post is the image 3rd from the right on the ioc list above the reply editor

u can paste the text

please use code blocks around
paste
select all the text you just pasted
press the </> button

Laz

@sdetweil I wanted to insert the file. I copied a large piece from the error file into a separate file. It turned out 311 KB.
If you insert this here by copying, then there will be a lot.

sdetweil

@Laz yeh. forum is a pain some times…

email to me, same userid at gmail

Laz

@sdetweil Yes, OK )

sdetweil

@Laz got it…

there is the error

[04.04.2023 20:12.18.185] [ERROR] Calendar Error. Could not fetch calendar:  https://calendar.google.com/calendar/ical/.....
internal server error

something happened at google…

and more importantly

[04.04.2023 20:06.53.607] [ERROR] Calendar Error. Could not fetch calendar:  https://calendar.google.com/calendar/ical/....
...
failed, reason: getaddrinfo EAI_AGAIN calendar.google.com
    at ClientRequest.<anonymous> (/home/vova/MagicMirror/node_modules/node-fetch/lib/index.js:1491:11)
    at ClientRequest.emit (node:events:513:28)
    at TLSSocket.socketErrorListener (node:_http_client:481:9)
    at TLSSocket.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:83:21) {
  type: 'system',
  errno: 'EAI_AGAIN',
  code: 'EAI_AGAIN'

we can’t find a path to the server for this…
all outside the pi… so no idea we can’t fix it…
but we keep trying (so that is good)

do you run a pihole ad blocker system? seen this a lot when pihole has a problem

Laz

@sdetweil Yes, I see mistakes now… (
They last more than an hour in the records and then apparently the requests stop.
There is no ad blocker on raspberries. There is just a standard image and then a mirror is installed with a minimum of additional modules.
I noticed in the errors that there is an error of my two calendars. Perhaps at some point really Google becomes unavailable…
Of course, I don’t turn to the calendar so often on my phone and computer.
But today, before loading the mirror, I noticed that the blue calendar has not been updated since April 4. Just the errors are dated April 4th. It turns out that when there are many errors, the module stops accessing the calendar? After all, it cannot be that Google was not available for so many days…

sdetweil

@Laz the EAI_AGAIN error is a networking error…

the library we use does the work , nothing in our code…
the code needs to get the IP address of the server to connect
it looks up the name to get the address
this failed… name not found

thats all we got… “we can’t look this up now, please try again”
no idea where in the network from the pi outward what error caused the failure