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.
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.
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
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…
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
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?
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
I am still getting the same (at least it appears as the same) error when some packages (in ZIP) uploaded from SMART mobile to SMART Connect, could not be processes by SMART Desktop. I cannot tell what could cause this, but from the previous correspondence, we see it could be due to various reasons. Hope ver. 7.5.7 will bring solution(s).
There is no significant data in these files - two are “Stop Patrol” markers of empty patrols and one is a few track locations. It should be safe to ignore these errors.
Hello all!
After the upgrade of database, SMART Desktop and Connect to 7.5.7, and using SMART Mobile 1.0.478, I still encounter my “old friend”, when some JSON packages (ZIP attached) sitting on Connect, cannot be processed by Desktop. Those seems to be some leftovers of patrol waypoints, but one seems to be observation point.
Did you solve this problem you had? I am having some issues with it. I just realized if the following scenario could generate (or contribute to) the problem. I created a single general user “monitor”, which is being used by all my monitors so they can upload the patrols through Connect from their smartphones. Any thoughts @jsimfukwe?
Hi @albert.aguiar,
Well, the issue is persistent and stubborn. I still have it with some of patrols. I basically settled with this issue, accepting that some data will be lost.
Cheers,
Josip
Hi Josip,
will you be at the user conference in Windhoek? It would be good oportunity to work together on that problem.
Most of your data seems to be waypoints e.g. tracks. Every device sending data to the queue has it’s own device-id. This id is used to match track data to patrols from the same device. The process is checking if the timestamp for such a waypoint lies between the start and end of a patrol. If it cannot find any matching patrol or on the other hand multiple patrols when they have overlapping start and end times it will not be processed.
The first problem can happen if the patrol was deleted in Desktop or if the Start-Patrol never was send to the server.
The second problem happens most of the time when the rangers forgot to stop the patrol and it runs much longer then expected. Many users then manually change the end time of the patrol in Desktop, but that can lead to the issue that there are still waypoints in the dataqueue with a timestamp after this new end time of the patrol.
If you want I can have a look at your server to check these entries, if you are not comming to the conference.
Hi Oliver,
Thanks on taking care! I cannot come to the conference, unfortunately! I know that users forget to end patrol. There were ideas how to mitigate this. I agree that in most cases the leftovers on server are just some waypoints, but I am surprised they can happen even if the patrol lasted for some 30 minutes and was properly ended.
Oliver, you still have admin access to our server. There are currently three unprocesable packages.
Greetings,
Josip
