[Bug] Delay in "Top Dump & Pumps" notifications

[velajos]

After running the program (with "Nearest Hour" active) for a few hours, the notifications do not arrive exactly at the selected time (at the beginning they arrive exactly at each selected time interval).

For example for 15 minutes:

At the beginning: (they arrive exactly)

1st notification: 01:00 pm
2nd notification: 01:15 pm
3rd notification: 01:30 pm
4th notification: 01:45 pm

After some hours: (the order is lost)

1st notification: 01:07 pm
2nd notification: 01:25 pm
3rd notification: 01:43 pm
4th notification: 01:51 pm

Perhaps the automatic restart of the program every certain time, for the case of the example, if it is restarted every hour, the problem is solved (tested by me, since I do it manually). And it could be added as an option.

Thanks @brianleect

[brianleect]

Not too sure why this is happening. Surprised that it seems that you seem to receive some alerts earlier than the specified intervals. I was expecting a delay due to possible time taken for parsing and sending certain messages over time instead.

Currently the main telegram group has shifted over to the latest version. Will see if I can replicate the same issue faced.

[velajos]

Not too sure why this is happening. Surprised that it seems that you seem to receive some alerts earlier than the specified intervals. I was expecting a delay due to possible time taken for parsing and sending certain messages over time instead.

Currently the main telegram group has shifted over to the latest version. Will see if I can replicate the same issue faced.

Hello, thank you for replying.

Actually it's not that they are early, it's that they are late.

For example:
1st notification: 01:07 pm (should have arrived at 01:00 pm).
2nd notification: 01:25 pm (should have arrived at 01:15 pm)

Of course this does not happen all the time, it happens sometimes. Maybe it gets saturated when it has a lot of notifications to send and that's when this delay happens.

But as I said, it can be solved if the program could be restarted automatically from time to time.

[brianleect]

@Juanjacinto123 Newest PR might be of interest to you. #70

Have not yet fully tested but shifted the version running in the telegram group over.
Will merge it with main once everything appears to work as intended.

Should fix the delay without needing to restart causing gaps of missing data by rounding down to nearest interval.

[velajos]

Greetings @brianleect , this correction you made works partially fine. By this I mean that for the hourly intervals, they arrive perfectly without delay. But for the case of the minute intervals, they also arrive fine but some reports are not generated.

See what happens in my case:

I use the hourly interval, but I also use the reports every 15 minutes.

After your correction now only the reports of the first 15 minutes after the hour and the last 15 minutes of the hour are coming. That is, if for example I am waiting for the 11:00 am reports, they arrive like this:

11: 15 Am and 11: 45 Am, (15m interval reports).

Before the correction they arrived like this:

11: 00 Am, 11:15 Am, 11:30 Am, 11:45 Am, 12:00 pm and so on every 15 minutes (with the problem of the slight delay).

And joining both intervals of one hour and 15 minutes, they arrive like this:

11:00 Am (hourly report).

11:15 Am (15 minutes report)

11:45 Am (15 minutes report)

12:00 Pm (hourly report)

In the past, they used to arrive like this:

11:00 Am (hourly report) and 11:00 Am (15 min report)

11:15 Am (15 minute report)

11:30 Am (15 minute report)

11:45 A.M. (15 minute report)

12:00 Pm (hourly report) and 12:00 Pm (15 minute report)

And so on.

Thank you for your response. Regards

[brianleect]

@Juanjacinto123 Thanks for bringing up the issue.

Just noticed that the initial code I pushed actually adds an unnecessary interval time. Which makes sense for defined 15m intervals resulting in 30m interval actual reports.

What's a little confusing however is that this additional addition only seems to reflect on the 15m interval and not on the hourly based on what you are reporting?

Looking at the current public facing group, we see the 3h alerts firing every 6h instead which makes sense. Can you confirm that you are receiving your hourly report actually every hour instead of every 2h? (Or is it actually a 30m interval you set triggering)

[brianleect]

I have removed the additional interval addition in the latest commit. Running 1h, 3h, 6h intervals on the main group now. Will see if this fixes the problem

[velajos]

@Juanjacinto123 Thanks for bringing up the issue.

Just noticed that the initial code I pushed actually adds an unnecessary interval time. Which makes sense for defined 15m intervals resulting in 30m interval actual reports.

What's a little confusing however is that this additional addition only seems to reflect on the 15m interval and not on the hourly based on what you are reporting?

Looking at the current public facing group, we see the 3h alerts firing every 6h instead which makes sense. Can you confirm that you are receiving your hourly report actually every hour instead of every 2h? (Or is it actually a 30m interval you set triggering)

Greetings my friend, happy holidays!

Well I tested it only with the 1h interval and apparently it worked fine sending the respective summary every hour. The problem appears when I add the 15m intervals, which is when the problem explained above occurs.

[velajos]

I have removed the additional interval addition in the latest commit. Running 1h, 3h, 6h intervals on the main group now. Will see if this fixes the problem

OK I'm going to try with this last update you made, with the 15m and 1h configuration. I will try a few hours and let you know if it is fixed. Thanks

[velajos]

Greetings @brianleect since early yesterday I was testing the new change and it seems that everything is working perfectly. All the summaries are arriving every 15m and without delay. I will let you know if there is any news. Regards

[brianleect]

Looks like everything is working well.