Tried with a different phone and Osmand, but it’s giving me the same issue.
Start = End = 1970-01-25 13:31:24
The track is shown correctly, but unfortunately the dates and times are wrong.
Plugin Author
tinuzz
(@tinuzz)
Sorry for the late reply, I have been traveling for the past 6 weeks. I am picking up Trackserver development now.
I’ll have a look if I can reproduce the issue.
Do you have the latest Trackserver, WordPress and OsmAnd versions?
Best regards,
Martijn.
Plugin Author
tinuzz
(@tinuzz)
Can you have a look at you webserver access logs and figure out what the timestamps that your WordPress receives from OsmAnd look like?
They should be in milliseconds sinds 01-01-1970 (something like ‘1450101110157’). I cannot reproduce the issue with OsmAnd 2.2.3.
The code that converts the timestamp for storing it in the database involves some timezone calculations, which are always tricky, but it seems unlikely that the resulting timestamp would be in 1970.
Is your timezone configured correctly in WordPress and/or PHP?
Hi Martijn,
Yes, I have the latest version of WordPress , Trackserver and Osmand.
My timezone is correctly configured in WordPress. Not sure about php, I must check that with Godaddy.
From the logfiles I read the following entry (I replaced username and key):
‘[13/Dec/2015:00:00:37 -0700] “GET http://www.vomac-nl.com/osmand/??lat=51.586636&lon=4.9822874×tamp=1449990037252&altitude=60.0&speed=0.0&bearing=0.0&username=xxx&key=xxxx HTTP/1.1” 200 18 “-” “Dalvik/1.6.0 (Linux; U; Android 4.4.4; Vodafone Smart 4 turbo Build/KTU84P)” ‘
The given timestamp is actually for a date in December 2015, so actual and not 1970.
I would be happy to send you my login details so you can have a look for yourself.
OK, I added the following line to php5.ini (hosted with Godaddy) and restarted ‘web processes’:
date.timezone = “Europe/Amsterdam”
The result is a change in start- and end times, but unfortunately they’re still in incorrect: 1970-01-25 21:31:24
Plugin Author
tinuzz
(@tinuzz)
Hm, there must be something wrong with the way I calculate the timezone offset for the timestamp.
Can you edit trackserver.php, and remove this line from the function handle_osmand_request():
$ts += $this -> utc_to_local_offset( $ts )
It should be line 1371 or close to that (my local version has some changes compared to v1.9, so it could be off by a few lines).
I’d like to know if the removal of that line makes a difference in the result. If it does, we know that it’s the timezone offset calculation that’s causing the problem.
Best regards,
Martijn.
Plugin Author
tinuzz
(@tinuzz)
Remove or rather comment it with //.
Hi Martijn, I commented it out with //
Start- and end are now both 1970-01-25 20:31:24
Plugin Author
tinuzz
(@tinuzz)
OK, then something else must be wrong.
How are your PHP / troubleshooting skills?
Around line 1429, there is this:
$this -> osmand_terminate( 200, 'OK, track ID = ' . $track_id );
This line can be changed to include any desired information, because I don’t think that OsmAnd cares about the output.
I would like to know the values of the following things:
$_GET["timestamp"]round( (int) urldecode( $_GET["timestamp"] ) / 1000 );$ts
If you can include that in the output and then try the OsmAnd URL in a browser:
http://www.vomac-nl.com/osmand/?lat=51.586636&lon=4.9822874×tamp=1449990037252&altitude=60.0&speed=0.0&bearing=0.0&username=xxx&key=xxxx
My suspicion is, that the timestamp is changed to 0 at some point, but I don’t know why.
My PHP skills are close non-existent, unfortunately š
I can read and, up to a certain level, understand what the code means but that’s about it.
Can you let me know what I need to do, i.e. which code to add in which file and how to get the ‘output’?
EDIT:
I figured I had to enter the code as follows:
$this -> osmand_terminate($_GET[“timestamp”], round( (int) urldecode( $_GET[“timestamp”] ) / 1000 ), $ts);
Now, when I open the url in a webbrowser I am getting output: 2147484
Which is, converted to humanly readable time, exactly the timestamp I am seeing in the track data.
Plugin Author
tinuzz
(@tinuzz)
After investigation, I found this to be a bug that only occurs on 32-bit systems.
OsmAnd sends timestamps in milliseconds since 01/01/1970, and that is a number that is too big for a 32-bit integer. When conversion to integer occurs in the code mentioned above, the result is always the same: 2147483647, which is ‘maxint’ on 32-bit systems (2^31 – 1). When divided by 1000 and converted to a timestamp, the result is always 1970-01-25 20:31:24.
This will be fixed in the next version of Trackserver, which will be released within two weeks.
If you need to use Trackserver with OsmAnd on a 32-bit system now, please contact me directly for a fix. Or if you are PHP-savvy, change the code on line 1370 or 1371 from this:
$ts = round( (int) urldecode( $_GET["timestamp"] ) / 1000 );
to this:
$ts = intval( substr( urldecode( $_GET["timestamp"] ), 0, -3 ) );
Thanks to Marc for letting me use his website for troubleshooting.
Cheers,
Martijn.
