Street name and lane marker disappear. #3898
Comments
|
Do we have this part of GPX file? |
|
I've asked for it. Will post it when the user responds. |
|
The video does not load for me. However it sounds like an issue I experienced on my old single core Nexus S phone, see #2962. |
|
I published the issue to Paul. It doesn't matter what street it's on, after a short while (usually within a few miles), osmand simply stops displaying the street names and lane indicators. It worked fine for months, then one day simply stopped working--I believe after an upgrade, but cannot recall the specific day. |
|
I have the app on another device running android 6.0.1, I've noticed that this bug does not appear on that device, only my tablet which is running 4.4.2. |
|
Very weird, I can almost 100% reproduce this on a Samsung S4 Mini with Android 4.4.2 stock ROM, in a simulation. Losing the street name display at almost the identical spots. But it does actually recover, also reproducible, at fixed locations:
It does not seem to be an issue with our reverse geocoding code, because if I manually select a point on the map at a stretch where (and during) the street name widget shows blank, the selected point's context menu correctly resolves and shows the address as e.g. "Greenbrier Parkway" (although that name could be retrieved from e.g. the opposite way of the divided highway. Looks like most or all occurrences happen on divided highways.) Rather weird, needs more investigation. I would normally suspect a mapping issue, but cannot find one at first sight. Maybe someone more experienced with mapping can take a look at the ways in question and check out if there is anything faulty. |
|
I'm an OSM contributor, and have examined various pathways where this occurs. At first I believed it to be because some points lacked road names, but then it would happen in places where there's no lack or break of road names. On my system, it sporadically "recovers", but only briefly. One day last week I was riding somewhere (nowhere near any of the locations in the evidence provided), and suddenly a street name popped up, but a few seconds later it did the "Near ...." thing, and then it dropped off again. If there's any specific roads I should examine in OSM, let me know. Personally, I don't think it's OSM-related, because it didn't do this prior to the recent upgrade. I'm more inclined to believe it's an implementation/method of code. I've also begun to notice that in Android 6x, the new version seems to lose track of GPS when walking, something it didn't do before--but that's for another thread. |
|
Thanks for investigating. Have you seen any occurrences on non-divided highways? Regarding loss of GPS on newer Android systems: Chances are this is related to new power saving features, check out e.g. #3923 (comment) . |
|
I see occurrences of this thread's issue everywhere. I haven't come across anything where it hasn't happened. First boot, "Road" shows up. A short while later "Near Road", and finally nothing. Regarding the GPS loss, I thought about power, but other GPS apps aren't losing it. For example, I stopped using OsmAnd to record GPX on my newer devices because it "can't see" the GPS for long periods of time, whereas my other GPS items (and GPX logger), never lose a connection. I examined my power options, I have all power saving disabled. |
|
I actually had a moment of surprise when the functionality remained intact yesterday for about 10 minutes before dropping out. No apparent reason why. |
|
This is an odd question, but is it possible the reverse lookup (which I'm presuming is whats being used to query the name for display), is timing out? Or whatever function passes the coordinates is getting backlogged or gets stuck? It seems like nearly every single "loss" is prefixed by the "near... road" display, which almost seems like OSM StreetName gets stuck on a node or street, and as I get further away its next update renders to "Near" that road, and then finally it just stops. |
|
Yes, I have a similar suspicion. But strangely, it seems that during such an "outage" I can tap any POI or long-tap any other point on the map and the popup context menu will actually correctly resolve and display its address. So it seems that not the reverse geocoding lookup gets overall stuck, but somehow maybe only the lookup process for the current/next street segment lookup. Not sure if that makes sense, but I think Victor (@vshcherb) needs to take a look at the symptoms we found, he had discovered and fixed similar reverse lookup process collisions in the past. |
|
I noticed today that for the brief amount of time it's working, if I'm near
a marker point such as a rail road, the icon will show up in the corner
like it should. It then takes a street change to disappear no matter the
distance away from the rail road. Not sure if this is helpful or not.
I'll try the manual reverse lookup myself since you mentioned it.
…On Jul 6, 2017 19:24, "Hardy" ***@***.***> wrote:
Yes, I have a similar suspicion. But strangely, it seems that during such
an "outage" I can tap any POI or long-tap any other point on the map and
the popup context menu *will actually correctly resolve and display its
address*. So it seems that not the reverse geocoding lookup gets overall
stuck, but somehow maybe only the lookup process for the current/next
street segment lookup.
Not sure if that makes sense, but I think Victor ***@***.***
<https://github.com/vshcherb>) needs to take a look at the symptoms we
found, he had discovered and fixed similar reverse lookup process
collisions in the past.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3898 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcPhMeNTHI0GpDeNpEEl1tuTB4xJqqDeks5sLWysgaJpZM4N1hnh>
.
|
|
I tried the reverse lookup as you suggested. I tried this after it had lost the street display. No-dice.. couldn't get it to reverse lookup anything by selecting a point. It shows the coordinates just fine, and then it'll say "looking up address" (or whatever), and that's all it does. I tried a bunch, moved around the map selecting different roads and buildings.. nothing, it just sits there in an endless "looking up address". I'll try it again before it loses street display. |
|
After a fresh boot of the tablet today, I waited until OSM had fully loaded in and the street name was showing. I used the reverse lookup to check various streets with success. After about a minute of moving down the road, the street/everything went out like usual, and reverse lookup stopped functioning. |
|
Not my observation, actually, but I may be wrong. I thougt the address lookup still works, it may just take a lot longer during an ongoing navigation, probably a matter of CPU performance. But I am afraid I was heading down the wrong track here anyway, because we do not necessarily use reverse geocoding lookup to determine the street name. EDIT: But processGeocoding in CurrentPositionHelper may be hung nevertheless, not sure. In any case, the fact that we always lose the display via a brief appearance of "Near ..." seems to indicate tthat to OsmAnd we are moving away from a named segment, so somehow when the condition occurs we seem to use use the orthogonal distance to a past portion of a way (and that distance is too far to detect we are on it) and not the portion we are actually on. |
|
Hardy: |
|
Another observation to add. I went a few miles yesterday and it worked
well, and near the end of my trip it "got stuck" on one road. I left the
tablet on and walked away for an hour or so . I came back and started
driving and as soon as I got going, the display "caught up", showing in
proper succession each of the roads I'd been down prior to it stopping
working. It then stopped displaying the roads altogether.
So I left it on overnight and when I looked at it in the morning, it was
showing the proper road. As soon as I took off driving, it stopped
displaying streets.
As to performance, it's a quad core 1.4ghz running no other apps. It never
had this issue before the upgrade.
…On Jul 8, 2017 07:41, "Hardy" ***@***.***> wrote:
Code ref to check: https://github.com/osmandapp/
Osmand/blob/master/OsmAnd/src/net/osmand/plus/views/mapwidgets/
MapInfoWidgetsFactory.java#L737
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3898 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcPhMWepgDjDtXlZtu5Wz8D3GVoCplkQks5sL2rkgaJpZM4N1hnh>
.
|
|
That sounds somehow like a process competition...something somehow taking REALLY long. And that matches my observation. And it seems perfectly reproducible when repeating the exact same steps e.g. by running a simulation along the identical GPX track. Can you specify with which update exactly you think this started? Thx! |
|
Whichever one provided the animation smoothing for your current location.. I want to say it was the most recent update. Also, if this is helpful, this doesn't occur during navigation (that I can recall, I will test it), but it's when I'm just riding around. |
|
When I simulate a navigation along the GPX track provided above, it seems to happen on my device at the exact same places as shown in the video (which shows the just-cruising case). I have however, not seen the effect (yet) for not simulated "real" navigation. |
|
After lots of more testing, it turns out this is not 100% reproducible. I simulated the stretch on Greenbrier Parkway in front of Greenbrier Mall now 12 times. In 10 cases, I lost the "Greenbrier Parkway" Display just after crossing Eden Way North, but in 2 cases I did get the display ok together with the "3 lanes" indicator just fine all the way to the I-64 ramp. I think we can rule out that this is a simple screen refresh issue because of this additional observation: The CPU consumption my Task Manager reports for OsmAnd even with OsmAnd in the background is really high after occurrences of this issue, about 50%-60% continuously until I kill OsmAnd. I clearly attribute this CPU consumption to continuous (or stuck) reverse geocoding lookup: Normally, when I have OsmAnd in the background in e.g. Browse map profile without street name display, OsmAnd CPU consumption is 0%. It only rises to double-digit values when manually starting a reverse address lookup, (like for a point's context menu), falling back to 0% as soon as the address is displayed. So it really looks like we are dealing with a process competition issue here. I now tend to think that this issue is an exact duplicate of #2962. |
|
PS: Also related to #2960 (comment). I guess we have to re-visit how we organize our reverse geocoding lookup, and also investigate to cache results to some extend because repeated attempts all the time are quite CPU/power intensive. |
|
Yeah, those threads sound exactly like my issue.
…On Jul 9, 2017 03:22, "Hardy" ***@***.***> wrote:
PS: Also related to #2960 (comment)
<#2960 (comment)>.
I guess we have to re-visit how we organize our reverse geocoding lookup,
and also investigate to cache results to some extend because repeated
attempts all the time are quite CPU/power intensive.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3898 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcPhMVSY14Gkq6BTdQo6A6fTlYrHn8qDks5sMH-qgaJpZM4N1hnh>
.
|
|
@sonora geocoding lookup - shouldn't happen during navigation. It uses navigational data which is precalculated. As I saw in the video it was a navigation case. |
|
I wasn't navigating anywhere in the video, I was just riding along. If
that's what you meant by navigation.
I just tried osmand on another device of mine running Android 6, quad
2.7ghz device. It happens on that as well, although not as quickly as with
my tablet.
…On Jul 9, 2017 17:53, "vshcherb" ***@***.***> wrote:
@sonora <https://github.com/sonora> geocoding lookup - shouldn't happen
during navigation. It uses navigational data which is precalculated. As I
saw in the video it was a navigation case.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3898 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcPhMSvmTELGH0HxKoqH_6ncHBCcPGOnks5sMUv0gaJpZM4N1hnh>
.
|
|
Victor, I was confused at first as well, but we are talking the non-navigation case here. Although I could also reproduce this using a simulated navigation in Follow mode. |
|
I just experienced some of these issues again during hiking. I had the walking profile active, so the street name widget was not enabled. Nevertheless after some hours I did encounter long delays on various actions. E.g. adding an OSM note or editing a POI. The corresponding dialogs did appear only after several minutes. |
|
I recently used this to navigate a short distance away from my origination point, it went fairly well. Later in the day another navigation episode was a little more rough, as a few times it had to reroute due to road construction, and at one point it took so long to reroute I simply pulled over and had to cancel it all out and reload everything. There's been a couple of times this week where its attempt to "catch up" was burning so much energy, the device was unable to "charge" and simply "maintained" its capacity at the same % for the duration. |
|
I ran this on a Note 4 Edge over the weekend, to monitor some OSM map changes over the course of a 5 minute trip. During this time, the street display washed in/out (as described in this thread), CPU usage was absolutely off the charts, and I lost 20% of the battery of the phone. This is absolutely ridiculous. I would have to put the device into an ARM stress test just to match the resources Osmand+ is using when this happens. On the bright side, if I ever needed to heat my hands up while in Russia during winter, I could just load the app and hold onto the phone. |
|
Can confirm excessive CPU-use upto 27%..when not displaying current streetname, lanes when in simple follow-me -mode. Even when OsmAnd is no longer running in foreground. On Samsung Galaxy Camera2, Android 4.3, 4 cores. |
|
In the interest of data points, I'll see if I can log cpu usage while using the app. Watching it the other day, cpu usage is 60-90% for all 4 cores on my device, at any given point. |
|
A week ago I said I'd start logging load to see if I can provide any further useful objective data. The purpose of this wasn't to prove this issue (as it has been observed by many), but to examine what it actually looks like, from a data-visual perspective. In order to monitor process usage and log CPU load, I used Cool Tool Pro from deviantstudio (https://play.google.com/store/apps/details?id=ds.cooltool). This lets you use a window overlay to monitor chosen fields. In my case, for the window overlay, I keep an eye on battery%, cpu load%, memory free, temperature, and most important, what system process is using the most resources. My observations: When not idle (ie, when simply moving on roads), usage typically bounces between 60-80%, with spikes to 100%. Navigation mode doesn't appear to make a difference (good or bad). I've also twiddled with GPX recording, it may make a hair difference (couple of %), but appears to be a victim of this issue more than anything. To try and provide a simple visual illustration of my findings, I transposed the CPU load log results with GPX recordings of trips, one data group using navigation to get to a destination, and the other was simply riding around town--the data was tied together using system timestamp. GPX interval for nav mode is 3s, while in explore mode is 2s. Below is a snapshot showing these two situations. The top chart is "cruise" mode, simply exploring, bottom chart is "navigation" mode. Red line is speed in MPH (axis to the right), blue is CPU load in % (axis to the left).
Notice in exploration mode (top), CPU load quickly ramps up to the 70% range and stays there until movement is at a stop, once at a stop it drops to the 30% range. Occasionally while at rest, it will spike--doubling--for no apparent reason. All of this usage is OSM+. The duration for exploration was around an hour--I truncated the speed timestamp of the tail because it was motionless, but allowed the load to be displayed to show that it was using very much CPU despite being at rest doing absolutely nothing. In navigation mode (bottom), you can see it's not much different. There's thousands more data points here due to the duration (5+ hours), so the chart is thicker. Again, OSM+ "idle" appears to just use 30% of CPU for no apparent reason (the 4 hour gap of being at rest), and its "normal operating load" appears to be 60-70% at any given point (which corresponds to the operating load for non-nav mode). For anyone curious, Base CPU load (booted but without osm+, doing nothing) is < 4%. Other data points I examined mirror this, OSM+ load at idle being very high, and while in use, more than doubles. My concern is that moving forward (building on the existing code/bug or whatever is causing this), is going to be hurtful to the app, because CPU usage makes it very inefficient. I believe it's also going to cause other issues, as more features will become available, but performance may be sluggish. The fact that I can install this on a new device, and drain the device battery by the second, is further proof of this. It seems there's an inefficiency in the code somewhere. I've mirrored these results on another device, and it's rate is no different. When I first got this app, I was excited at the prospect of being able to explore and see the current road and the number of lanes, because I'm an OSM developer, and this helps me test changes in the real world environment. With this inefficiency, I can no longer do that, because these displays disappear, as mentioned in the beginning of this thread. |
|
Here's some screenshots showing the user-side of the data collection. I was travelling yesterday as a passenger, and had the chance to capture these. The first one shows you the base performance of the tablet with everything but OSM+ loaded up.
The following are some shots taken a few seconds apart. Note the lack of street name/lane markers, which disappeared moments into loading OSM+, as the CPU load ramped up.
Notice with the load being so high, when OSM+ goes to automatically change zoom levels based on speed, it's unable to clearly render the map for a short amount of time, and the overlays disappear.
This lag of drawing map on the screen (somewhat) demonstrates one of the observations I make earlier in the thread, where driving at night, the screen will often flash bright white as it loads new segments of the map, but CPU load is so high, it loads them in "day" mode before "slowly re-drawing them" in night mode (which is the darker theme). |
|
The day/night mode observation is a separate issue and should not matter here. I also occasionally observe this, as follows: Normally, when the map is panned, the background default color should be that of the mode in which the map is displayed (at least ever since v2.8.x or so), e.g. dark green for night mode, something grey/whitish for day mode. It seems that when sometimes OsmAnd switches from an app profile which uses day mode to one which uses night mode (or maybe also when the day/night mode switches based on sunrise/sunset, not sure), the panning of the night view map still appears on the gray/whitish background, producing the "flashing" appearance. Killing/re-starting the app at this time fixes it. But this issue should not be the prime root cause for the CPU usage here. |
|
I just presumed it may have been an offshoot, because it will sometimes take 2..5..12 seconds for the map to colorize properly, as I am travelling. In other words if I am travelling south, the bottom half of the screen will be tiles of day mode, which eventually turn dark. I just presumed the high CPU load was causing it to "take awhile". Your description of it matches mine, it is a very good description. |
|
To get back to the original issue: Are we quite confident the high CPU usage is
|
|
On point (1), It absolutely occurs regardless of motion--while completely at rest. Here's a series of tests I ran lastnight using the same methodology as before. I only plotted load this time, no speed (no motion..). Device was powered on and left abandoned for periods of time. Capture intervals for data points was 10sec. I clipped out the first 30 seconds of boot time, as that would prejudice the chart. What is seen below is the device simply at rest:
There are four tests, all of them the same except for test 3. For this particular test, I blocked the GPS from being able to receive a signal. This shows OSM doing something, even when no GPS data is being parsed. 30% load with 0/0 for satellite signal. As to point (2), I can run the same test with the street display disabled. |
|
Very interesting. So it seems what you see is not related to map rendering, as the map remains stationary. We must be doing something else continuously using lots of CPU. Not sure I can reproduce the observation though: On Samsung devices, and using Samsung's built-in "Active apps" monitor, OsmAnd's CPI usage seems to strictly drop to 0.00% when OsmAnd is in the background (and the app monitor is in the foreground): When in motion after latest 3 seconds from when switching from OsmAnd to the "Active apps" app. And when performing that switch while at rest, the Active app monitor immediately shows OsmAnd using 0.00% CPU, which seems to indicate that is also the value for when OsmAnd is in the foreground. So I cannot actually confirm the observation OsmAnd is using any CPU at all, unless
|
|
This is a Samsung tablet I'm using, as I've stated before. I can also reproduce it on a Samsung Note 4 Edge, but I used the third party app to provide objective raw usage of hardware, which could then be written to a log file. I have no idea how Samsung's applet work. Now, as promised, here's my data from point (2), where I disabled street display.
Completely motionless with street displays disabled, there appears to be no difference with the previous test (street displays enabled). Combining these results, with the previous--particularly noting the CPU usage with GPS signal blocked--as an outside analyst, I can only conclude something in the code is burning up CPU slices in a loop, and it only gets worse when there's GPS data stream involved. That it grows significantly with higher speeds (thus, more GPS data/longer distances between points), only adds to the theory. Again, baseline study of the device without OSM+ loaded, shows 0-4% CPU usage at most--typically 0-1%. The other 20-40% is coming from OSM+, for whatever reason. I've run a few other apps, including Nav apps, just to test. They don't appear to have the strain/drain OSM+ does. I will examine them in more detail. |
|
I have seen the high CPU-use as well on Samsung Galaxy Camera 2 (in latest nightlies) Only after a search for address or POI is completed, the CPU-use goes back to normal... Good luck investigating. |
|
Thanks for that input CJ, I will try the POI/address search you suggested, to see if that does something. |
|
To the developers: Please just use a profiler. It shouldn't be too hard to identify the cause of this high CPU consumption. Fixing this bug will help a lot of your users and improve one of the main point of criticism of OsmAnd (= consuming lots of CPU / battery). |
|
Rounding the corner on almost a year old, I wonder how the progress is? I haven't had a chance to do any additional debugging since my last post, I've been very busy :( I can no longer reliably use OSMand for navigation purposes due to the CPU load. A couple of times in the past month I've needed to navigate somewhere and would input the location. Inevitably I'd choose a destination, and it would take ages to calculate. Eventually it worked, but I would have to change route due to some issues, and recalculation simply took forever--and every intersection was a recalculation, so this forced it to just keep lagging and lagging. Ended up just killing it off and toggling over to google maps, it was up and running to my nav point within 3 seconds, with no issue. I simply use OSMand for general quick-visual reference now, the CPU overhead is simply too great to do anything else with it. It still burns a hole in my hand if I use it on a more modern device, where the battery drains as quickly as pouring water from a glass. |
|
I guess here there were measurements about navigation mode without calculating route, so in that case "reverse geocoding" is happening every 50 meters which is very CPU expensive for each call. Unfortunately no progress was made in that direction |
|
CPU load is high sometimes, even while navigating along a calculated route. And even while standing still, even when OsmAnd is running in background..... Unfortunately |
|
@vshcherb as @CJTmmr and some others have pointed out, it's not just in one mode, it's in every mode, whether calculating or not, whether in navigation mode, or in exploration mode. Something is clearly going on. Seeing all of the new bugs popping up, all in some way relating to 'slowdown', on brand-new multi-core very fast devices... this is pointing to something eating up processor time. I can play HD games on my new phone and use less battery than OSM will just driving around. Yes, it is unfortunate no progress has been made to route this out, as mentioned last year, this will continue to plague OSM until fixed. This issue was formerly tagged as a milestone event, but appears to no longer be the case. Rolling out new features is great, but shouldn't be a focus until foundational problems are resolved. Not sure why this isn't in the top 3 priorities. Just speaking from an outsider's perspective, of course. |
|
While it's great to see OSMAnd is at a whole new version, and all sorts of features are being added, it would be great to fix underlying issues. Like #3898. |
The street name and lane marker show up like normal when I start riding, and once I turn off of that first road, they disappear and never come back.
Android 5.1.1, OsmAnd version 2.6.5
Video: https://drive.google.com/file/d/0B_epabEezdJreFV4Ql8wLWd6eEk/view?usp=sharing
The text was updated successfully, but these errors were encountered: