Call Monitoring doesn't work after a time #8

New Issue

homer77 · 2021-07-02T09:00:59+02:00

homer77 commented

2021-07-02 09:00:59 +02:00

At least on one of the test machines

the docker container is running
the python process is running

but after a call or even leaving a message nothing is happening. Neither in the log nor with the process.

There need to be more checks in the lib.monitoring to find out if Monitoring is at least running.

An alternativ would be to run the script with a cron job instead of CallMonitoring. But it feels less elegant.

Sidetrack: I need to find out, how I get every output into the logs ...

At least on one of the test machines * the docker container is running * the python process is running but after a call or even leaving a message nothing is happening. Neither in the log nor with the process. There need to be more checks in the _lib.monitoring_ to find out if Monitoring is at least running. An alternativ would be to run the script with a cron job instead of CallMonitoring. But it feels less elegant. Sidetrack: I need to find out, how I get every output into the logs ...

homer77 added the

bug

label 2021-07-02 09:00:59 +02:00

homer77 commented

2021-07-02 13:42:23 +02:00

Update:

Interestingly after a received call some hours later I suddenly received the old message over matrix!

So it isn't like the programm/processes weren't working but obviously CallMonitoring is a little more complex as I thought and there might be some delay times that I yet don't understand.

Update Next Day:

Next day, another test. Left a message on both boxes.

Box 1
- Worked immediately. Received the messageo.
Box 2
- No reaction. Nothing in the logs of the docker container.
- I call again but break the call before voicebox answers ("DISCONNECTED")
- Process awakes, some seconds later I receive the message from the former call and I can see the matrix-commander feedback in the logs.

This seemed likewise the evening before. So it seems that the CallMonitoring doesn't work on Box2 when I leave the message but if another call is disconnected.

## Update: Interestingly **after a received call some hours later** I suddenly received the old message over matrix! So it isn't like the programm/processes weren't working but obviously CallMonitoring is a little more complex as I thought and there might be some delay times that I yet don't understand. ## Update Next Day: Next day, another test. Left a message on both boxes. * Box 1 * Worked immediately. Received the messageo. * Box 2 * No reaction. Nothing in the logs of the docker container. * I call again but break the call before voicebox answers ("DISCONNECTED") * Process awakes, some seconds later I receive the message from the former call and I can see the matrix-commander feedback in the logs. This seemed likewise the evening before. So it seems that the CallMonitoring doesn't work on Box2 when I leave the message but if another call is disconnected.

homer77 self-assigned this 2021-07-02 13:49:16 +02:00

homer77 added the

unconfirmed

label 2021-07-19 09:05:12 +02:00

homer77 commented

2021-07-21 17:13:40 +02:00

The problem is that obviously the new message isn't yet in the list the fritzbox sends . So the script is fired after the disconnect of the call but it seems to be so fast that the message isn't yet appearing but one call later it is.
Why this isn't happening at the other test environment isn't clear.

Maybe a short delay by 'time.sleep(4)' will prevent this from happening?

The problem is that obviously the new message isn't yet in the list the fritzbox sends . So the script is fired after the disconnect of the call but it seems to be so fast that the message isn't yet appearing but one call later it is. Why this isn't happening at the other test environment isn't clear. Maybe a short delay by 'time.sleep(4)' will prevent this from happening?

homer77 referenced this issue from a commit

2021-07-22 09:33:46 +02:00

Fixed issue #8 by adding a 5sec delay with time.sleep(5) to multitam(). Request for messages was too fast so that the new message wasn't in it yet.

homer77 closed this issue

2021-07-22 09:35:43 +02:00

Sign in to join this conversation.