Hi all,
This is an old issue reappearing to me from testing phase of SMART 7.x. Our on premise Connect server is updated to components from 2023, the mobile and desktop versions as well, but still the number of unpossessable JSONs accumulates as the number of mobile app users increase and is currently at 25. Some packages are waiting for 2+ weeks and still stuck. Waiting for many cycles for packages to be processes does not help. Some packages are stuck as queued, some as being processed, but never get there.
Another issue (may be related to stuck JSONs - I do not know) is that when downloading packages from Connect, I often get the message as this:
I always click on “YES”, accept loosing one point, presumably of patrol, and the package is processed.
I attach from Connect downloaded packages, which cannot be processes and log files from SMART Desktop. If server logs are needed, then I will ask our admin to provide.
JSONs_Stuck_on_Connect_JK.zip (750.3 KB)
SMART_Desktop_log.zip (497.4 KB)
Hope this help understanding the challenge.
Cheers,
Josip
Hi Josip,
As I understand the processing algorithm it requires that the time stamp of waypoint (track) needs to be between the start and end time of the patrol. There seem to be some phones out there where especially at the end of the patrol is recorded before the last waypoints. Maybe this is coming from different internal time sources used for collecting the time stamps of patrol data and track data.
Your last example clearly shows that problem as the last waypoint cannot be processed.
In general the matching algorithm uses the time stamps and the device id to identify the correct patrol the track data should be attached to.
To solve the issue you might either ignore these waypoints and just delete them from the queue or slightly adjust the end time of the patrol
Oliver
Thanks Oliver!
If the time of some smartphone is the problem, then it might be related to the “Use time from GPS” in settings for “SMART Mobile device Settings”. I used this option until now. Will try with this option disabled.
Loosing one point of the patrol is not a problem. I will just delete packages in queue. We will see what will be once mobile users update their packages.
I will provide follow-up on this in a while.
The mystery of fetching proper time (from GPS signal?) on some mobile devices remains…
Cheers,
Josip
@josip.kusak Let us know if your problem has been solved with regards to the time issue or if there is still a problem
Regards
Yes I will. It takes time for users to upgrade packages which do not have “Use time from GPS”, and especially that this is done by those which have devices creating problems.
Cheers!
Josip
Well, there is something new! I have now a package where most of waypoints cannot be processed.
9f6cd3f750374e1bb21ea3e2c696fb45.zip (446.2 KB)
One of two packages in the attached ZIP.
Hi Josip,
Sometimes it’s possible to resolve unprocessed packages by editing the start/end time of patrols that have arrived in Desktop. If two patrols from a phone have been started on the same date, and the end time of the first patrol hasn’t processed then it will be given a default end time of 23:59 and therefore overlap with the second patrol. Manually set the end time of the first patrol to be just before the start time of the second patrol and try again.
Also, some packages can be duplicated on the server. Not sure why this happens but it does. One copy will process OK but the other will just requeue and you don’t know that it had a successful duplicate so can be safeuly ignored/deleted.
But sometimes the reason they wont process is inexplicable (to me) - date and time fits within bounds of an existing patrol, phone ID matches, but no.
Jeremy
Thanks Jeremy!
I do not understand how two patrols from the same phone could be overlapping? One patrol cannot start as long as the previous one is active?!
Even if I would distinguish two overlapping patrols on the server by looking at partial JSONs by device id, how could I edit end time of JSONa on server? Download it locally, edit and then upload back to server?
On top of presumably overlapping patrols, now I got another issue resulting with unprocesable package. Some images are unprocesable and if I click “NO” when offered to ignore this error, those packages get stuck on server, see screenshot:
I am getting overflown with the variety of errors. Is there any recent upgrade (particularly of server) which needs to be implemented? We have a server on premise. Will anyone notify us there is a need to update/upgrade some server components?
Cheers,
Josip
… and many more unprocesable waypoints from one device:
Getting desperate!
