cgeo 🚀 - No logs for users without date format preset

That's the same error pattern as was caused by the Dateformat parsing bug. Can you check with them if they have an unusual Dateformat set?

pstorch on 25 Oct 2016

The date format doesn't look that unusual. Here is his whole system information.

--- System information ---
Device: SM-G920F (zerofltexx, samsung)
Android version: 6.0.1
Android build: MMB29K.G920FXXU3DPEU
Cgeo version: 2016.10.23
Google Play services: enabled
Low power mode: inactive
Compass capabilities: yes
Rotation vector sensor: present
Orientation sensor: present
Magnetometer & Accelerometer sensor: present
Direction sensor used: rotation vector
Hide own/found: false
Map strategy: auto
HW acceleration: enabled (default state)
System language: fr_FR
Log date format: 25/10/2016
Debug mode active: no
Geocaching sites enabled:
   geocaching.com: Logged in (Connecté) / BASIC
Installed cgeo plugins: calendar, contacts
--- End of system information ---

samueltardieu on 25 Oct 2016

Indeed that is not unusual.

pstorch on 25 Oct 2016

But you're right, this is not the date format from the site, but the date format that will be used to present logs locally. I'll ask him.

samueltardieu on 25 Oct 2016

Just tested with master a few patterns. Looks like MMM/dd/yyyy (Oct/25/2016) doesn't work.

pstorch on 25 Oct 2016

He is using "25. 10. 2016" ("d. M. yyyy", spaces included).

samueltardieu on 25 Oct 2016

Funny (or not) the pattern I mentioned works now. I'll try the one you mentioned with the spaces.

pstorch on 25 Oct 2016

It looks like the pattern with the spaces works as well. The date themselves don't contain anything encoded (they come from a JSON object and are clean), and the format even with spaces is nothing exotic.

samueltardieu on 25 Oct 2016

Funny (or not) the pattern I mentioned works now. I'll try the one you mentioned with the spaces.

Did you restart cgeo? If you change the pattern and don't restart cgeo, the old one might still be used by the application.

samueltardieu on 25 Oct 2016

Funny (or not) the pattern I mentioned works now. I'll try the one you mentioned with the spaces.

Did you restart cgeo? If you change the pattern and don't restart cgeo, the old one might still be used by the application.

Exactly that was my error.

Both formats work for me, when I restart c:geo.

Can you ask them to try another Format (just to narrow down the problem)?

pstorch on 25 Oct 2016

Yup, done.

samueltardieu on 25 Oct 2016

(btw, I've added the date format from gc.com to the system information in a7926a63b7697029e8d0df35f15240bbd1319b18)

samueltardieu on 25 Oct 2016

👍1

Switching to 25/10/2016 format made the user get the logs back. We still have no hint about what went wrong at this time.

samueltardieu on 26 Oct 2016

More users on support (see also #6058):

First feedback from a user on support. He is using:
26. 10. 2016

Additional feedback of this user: After changing to 26.10.2016, relogin and refresh of the affected caches all is fine.

Lineflyer on 26 Oct 2016

Could we please add a debug log info in this procedure logging what date format has been parsed? Or even add this info to the system information?
This will make it easier to test and support in case this happens in future.

Lineflyer on 26 Oct 2016

Summary of today (see also IRC log of today):

We did not find any cause yet
It does not seem to affect all users but a not yet known percentage (lot of bad ratings and FB posts for a working day)
It might be related to formats which include spaces
New user (who never touched the settings) was tested by @pstorch without negative result
Not reproducible for anyone of the team
Change of date format to something without spaces seems to solve the problem for users

Lineflyer on 26 Oct 2016

This might be related: Sometimes (or always?) geocaching.com responds with a really unusual encoding/html escaping: https://geoclub.de/forum/viewtopic.php?p=1259255#p1259255

class="LoginContainer LoggedIn"

class="LoginContainer&#32;LoggedIn"

I'm not even sure if this is allowed. But we could try to match it in the date. It wouldn't hurt and might fix the problem.

SammysHP on 27 Oct 2016

I'm not even sure if this is allowed.

It is not. According to https://www.w3.org/TR/CSS22/syndata.html#characters (second item → identifiers), it is not an identifier. On the other hand https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#classes requires a set of space-separated tokens, whereas space does not include  .

UniQP on 27 Oct 2016

This has been done already, on both release and master branches.

Le mer. 26 oct. 2016 à 21:54, Lars [email protected] a écrit :

Could we please add a debug log info in this procedure logging what date
format has been parsed? Or even add this info to the system information?
This will make it easier to test and support in case this happens in
future.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cgeo/cgeo/issues/6065#issuecomment-256458717, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACucNiDiKaBCgFtyfFTbmEYwpQlPU4fks5q37AMgaJpZM4KgZ5O
.

samueltardieu on 27 Oct 2016

This has been done already, on both release and master branches.

What is "this" in this case?
Did we have any success in finding the remaining bug?

Lineflyer on 27 Oct 2016

I guess @samueltardieu is referring to

Could we please add a debug log info in this procedure logging what date format has been parsed? Or even add this info to the system information?

rsudev on 27 Oct 2016

Added FAQ entry and pushed a notification with link to FAQ (workaround description).
Still of course bad rating and support requests keep coming :(

Lineflyer on 28 Oct 2016

I'm premium user from gc, use c:geo and know something about Software (embedded Systems). I dont't know how c:geo works in detail. But maybe this is a hint. I think while login at gc c:geo fetchs the users preferences, from the prefences web seite. There the fomat "29. 10. 2016" ist coded as.

"d.&#32;M.&#32;yyy
<label for="SelectedDateFormat">Date Format</label><select data-val="true" data-val-required="The&#32;Date&#32;Format&#32;field&#32;is&#32;required." id="SelectedDateFormat" name="SelectedDateFormat"><option value="d.&#32;M.&#32;yyyy">29. 10. 2016</option>
<option value="d.M.yyyy">29.10.2016</option>

If c:geo now (after twice logins ) get "d. M. yyyy" as search pattern, but de Cache Log-Site coded it without #32;: as

","Created":"9. 10. 2016","Visited":"9. 10. 2016",
initalLogs = {"status":"success", "data": [{"LogID":643059796,"CacheID":2517471,"LogGuid":"de1de195-9fcd-45ee-97e2-b8c37045a516","Latitude":null,"Longitude":null,"LatLonString":"","LogType":"Found it","LogTypeImage":"2.png","LogText":"<p>Jaa, habe ihn eben erfolgreich geloggt. Details trage ich zuhause am PC nach.<br />\nTFTC und Danke fürs Herlocken<br />\nbalu2003  #92</p>\n","Created":"9. 10. 2016","Visited":"9. 10. 2016",

maybe the search pattern fails in this case while parsing the cache's html site.

(sorry my english is worse)

balu2003 on 29 Oct 2016

in the comment above the replacement for space consisting of # followed by 32 and ; was automatically converted to spaces, so you don's see the difference beetwen preference pattern and caches's html.
Dont' know how to show that there are is #32 inside the optio value:
option value=d. M. yyyy 29. 10. 2016

balu2003 on 29 Oct 2016

@balu2003 the space encoded as   is already taken care of.

pstorch on 29 Oct 2016

@balu2003 if you want to encode something here in comments use backticks `

pstorch on 29 Oct 2016

I have made some tests and can reproduce an empty logbook. But it is a long listing. Should I post it here or send via email? to whom?

balu2003 on 30 Oct 2016

you can send it to [email protected] with reference to this issue if you think it is too long for a comment. Or you use pastebin or a similar service and post a link.
We welcome any hint that leads us further, as none of us was able to reproduce that issue yet.

rsudev on 30 Oct 2016

mailed it to support

balu2003 on 30 Oct 2016

Any news on this topic?

Regarding support mail: I am on the road and not able to access it. So I cant forward the info from @balu2003. Maybe someone else of the team can forward it.

Lineflyer on 30 Oct 2016

I found something with the rarely used account of my wife. Further investigating ...

pstorch on 30 Oct 2016

I've sent a PR for release branch. There are GC profiles without the date format selection, so the regex failed and we haven't set the fallback.

In master this needs to be done a little bit differently, because @samueltardieu eliminated the regex with JSoup HTML parsing. Which is much better, but still we need to set the default date format as a fallback, when no custom date is selected / found on the preferences page.

pstorch on 30 Oct 2016

@Lineflyer do we plan to release another version from release branch? I would prefer to fix it in master and release from there.

pstorch on 30 Oct 2016

I have no clear preference, but as releasing from master would need quite some time of testing for me I guess from release would be more safe.
Given that quite some users claim problems I would suggest to go for a fast release with no risk of bringing in even more problems.

Can someone take care to generate and publish a release from release as I am on the road until Wednesday at least and dont have anything else than my mobile phone with me.

Regarding the issue itself:
How can that be that there is no such field? Anyway...fallback to a certain format is just guessing then..or not?

Lineflyer on 30 Oct 2016

Corrected above I meant release from release of course.

Lineflyer on 30 Oct 2016

Here is the part of the preferences HTML I got from this account:

<label for="SelectedDateFormat">Date Format</label><select data-val="true" data-val-required="The Date Format field is required." id="SelectedDateFormat" name="SelectedDateFormat"><option value="d. M. yyyy">30. 10. 2016</option> <option value="d.M.yyyy">30.10.2016</option> <option value="d.MM.yyyy">30.10.2016</option> <option value="d/M/yy">30/10/16</option> <option value="d/M/yyyy">30/10/2016</option> <option value="d/MM/yyyy">30/10/2016</option> <option value="dd MMM yy">30 Oct 16</option> <option value="dd.MM.yy">30.10.16</option> <option value="dd.MM.yyyy">30.10.2016</option> <option value="dd.MM.yyyy.">30.10.2016.</option> <option value="dd.MMM.yyyy">30.Oct.2016</option> <option value="dd/MM/yy">30/10/16</option> <option value="dd/MM/yyyy">30/10/2016</option> <option value="dd/MMM/yyyy">30/Oct/2016</option> <option value="dd-MM-yy">30-10-16</option> <option value="dd-MM-yyyy">30-10-2016</option> <option value="d-M-yyyy">30-10-2016</option> <option value="M/d/yyyy">10/30/2016</option> <option value="MM/dd/yyyy">10/30/2016</option> <option value="MMM/dd/yyyy">Oct/30/2016</option> <option value="yyyy.MM.dd.">2016.10.30.</option> <option value="yyyy/MM/dd">2016/10/30</option> <option value="yyyy-MM-dd">2016-10-30</option> </select><label for="SelectedGPXVersion">GPX Version</label><select id="SelectedGPXVersion" name="SelectedGPXVersion"><option value="1.0">1.0</option> <option selected="selected" value="1.0.1">1.0.1</option> </select> <div class="checkboxes-wrapper"> <label> <input checked="checked" data-val="true" data-val-required="The Show other geocachers' profile photos in logs field is required." id="ShowAvatarsInCacheLogs" name="ShowAvatarsInCacheLogs" type="checkbox" value="true" /><input name="ShowAvatarsInCacheLogs" type="hidden" value="false" /> <span>Show other geocachers' profile photos in logs</span> </label> <label> <input checked="checked" data-val="true" data-val-required="The Block friend requests from other geocachers field is required." id="BlockFriendRequests" name="BlockFriendRequests" type="checkbox" value="true" /><input name="BlockFriendRequests" type="hidden" value="false" /> <span>Block friend requests from other geocachers</span> </label> </div>

As you see, no selected date format. But the Regex (used in release) fetched the next selected option 1.0.1, which isn't a date format of course. I'm not very happy with my Regex for the release branch fix, that's why I would prefer to make a new release from master. Or we could also cherry-pick @samueltardieu 's change which uses JSoup to parse the preferences page.

I think the fallback is not guessing. We already have the fallback in GCConstants.DEFAULT_GC_DATE which is the default english date pattern MM/dd/yyyy. It was just not set, when problems in detecting the custom date occurred.

pstorch on 30 Oct 2016

I don't know why some GC profiles don't have a custom date format set. As we saw earlier, newly created accounts have one set. I can only guess, that for some older accounts they haven't properly migrated the profiles at some point. Only guessing.

pstorch on 30 Oct 2016

But for now you did not change the regex again compared to current market releae but only catch the failure and set a default?!
In this case its very fine for release as it can only make things better. Dont you think?

Lineflyer on 30 Oct 2016

@samueltardieu Given what I wrote above is correct I vote for a release from release branch. What is your opinion?

Lineflyer on 30 Oct 2016

@Lineflyer for release branch I had to change the RegEx again, because it fetched a wrong one.
For the fix in master, there is no RegEx anymore.

pstorch on 31 Oct 2016

How about putting a RC based on release to the beta channel. In case something went wrong with the new regex we might get beta feedback?!

Lineflyer on 31 Oct 2016

👍1

Tested using 2016.11.01-RC with all available date formats:

All format recognized (Comparison between website selected format and date format shown as detected in c:geo system information)
Tested loading a cache and checked logbook dates and hidden date

Will upload this RC to the beta channel now.

Lineflyer on 1 Nov 2016

For future reference: https://www.dropbox.com/s/36pp5l8rt8ahwbh/dateformats_cgeo_20161101.xlsx?dl=0

Lineflyer on 1 Nov 2016

👍1

Cgeo: No logs for users without date format preset

All 43 comments

Related issues