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!
It seems I am the only one with this kind of problem(s).
Hi Josip
Just want to follow-up here and see if you are still receiving errors?
Are the rangers ending the patrols correctly? Are they potentially pausing and forgetting to resume patrols? (This can potentially cause the overlap and the accuracy error you getting)
Did they potentially turn location services on the devices off by mistake?
Just need to ask as these errors are sometimes results of data collection mistakes being made.
What Local Connect server version are you running?
Hi Joachim!
Thanks on taking care of this topic!
I do not have any more cases where thousands of waypoints could not be imported, but only the last one or two waypoints only. I do not know if all users work with patrols properly as you asked about, but I do it as supposed and the error of one-two waypoints being unprocesable still appears occasionally, even for my own patrols. Oliver suggested there is difference in patrol end time which is measured in milliseconds and that this will be resolved in the next update (7.5.7).
Another issue in this thread is that some of photos could not be processed, as earlier screenshot shows. Oliver suspected the files might be to large. The mobile package creating those images is set to resize them to 1600 x 1200, but this was not the case from the beginning. Some field users may have not updated the package.
The desktop SMART is 7.5.6, while the Connect server is 7.5.3
Cheers,
Josip
