How many retries for invalid event? #169
Comments
|
The way it works is as follows
|
|
Got it, thanks |
|
Hmm, something odd here, this one doesn't want to die: This is an extract from the log filtered on the event ID. Note how it keeps doing the 5 x times, but it's not incrementing the total discard attempts, it just keeps repeating: |
|
If I grep for this event failing: So there are times it does increase the count (it got up to 4 on one occasion), but it resets and starts again. In total it has now tried to get this event 215 times. |
|
This code: ...has not been triggered at all: OK, working through this... The code has this timer: So the problem here is that it's not trying the required number of times inside the timer: It got to 4 inside that 12 hours, but then resets. So either the timer needs to be configurable (longer), or the number of retries does, or the speed with which it retries. As it stands at the moment, this code is going to keep on retrying to get these clips forever, and will never mark them as permanently unobtainable. |
|
@ep1cman - any ideas on this? |
|
OK.... radio silence all round here. |
|
Dude I have a life outside of GitHub. I'm sure you can figure out that December is a busy month for many folks. 5 days is not radio silence, I've been away for a week for my day job with zero time to even look at GitHub. Nagging me and making these sorts of comments gives me no motivation to look into your issue any faster. Please consider the human at the other end, and the fact this is not their job. If you want to manually ignore an event, edit the sqlite file |
|
I apologise @ep1cman Sebastian, no offence was meant. |
|
While agree with your conclusion here, I don't understand how come it took so long for it to retry. The missing event checker is configured to check every 5 minutes. So what should occur is:
Assuming the intial 5 download failures take negligible time, this whole process should last no more that 100 minutes, well below 12h. Are the logs above edited at all? Im surpised to not see the |
|
The logs were grepped: |
|
upb.txt Note there were other video events between these, this log file is grepped on the event id 67638d5d02d15003e400e033. |
|
Are you able to provide a non-grepped log? I am interested in seeing when the missing event checker is firing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
0.11.0
5.0.34
As per container
RHEL9
Docker
Description
For some reason my UNVR had a bit of a glitch yesterday and I had to hard reboot it (it lost comms to all cameras and the network).
After the reboot, UPB regained comms to the UNVR and resumed connection and working.
But, it ran into an issue with a missed evnt:
It retried every 5 minutes for 5 times with the same result, then giving this:
Five hours later it "re-discovered" the missing event, and started the cycle again:
...again doing 5 attempts, an dfailing:
We are now up to the 7th attempt of 5 attempts:
How do we make it actually GIVE UP on this clip? How many goes will it continue to do?
Comment too: the logging refers to a batch of 5 attempts as "download failed after 5 attempts" and then seems to do batches of those, with each batch also being referred to as a "download attempt". Am I reading that correctly? If so, perhaps referring to them as "Event failed download set 7" may be better?
What I Did
see comments above.
The text was updated successfully, but these errors were encountered: