Street name and lane marker disappear.

[PaulStets]

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

[vshcherb]

Do we have this part of GPX file?

[PaulStets]

I've asked for it. Will post it when the user responds.

[PaulStets]

Here it is: https://www.dropbox.com/s/jx7d5f16vc24dzi/2017-06-03_16-59_Sat.gpx?dl=0

[polarbearing]

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. Naturally, when the street is not recognised, there is no lane information. Did not yet have the issue on my current multicore device.

[tazva]

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.

[tazva]

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.

[sonora]

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:

• In your video, the first loss happens at 1:31, going from "Butts Station Road " via very briefly showing "Near Butts Station Road" (which seems to indicate OsmAnd somehow moves away from a named way segment) to blank, but it recovers at around 1:44.

• Your second occurrence happens at 3.46 losing "Greenbrier Parkway", again via a brief appearance of "Near Greenbrier Parkway". It does not recover in the time span of your video, but when I simulate this, it actually recovers after pulling onto I-64, when it starts displaying "I 64" about near http://www.openstreetmap.org/way/391802357. Very briefly only, however, as more losses occur thereafter when proceeding down I 64. The next brief appearance of "I 64" is right after the Indian River Road bridge. These losses and re-coveries seem to reliably happen at reproducible points, I think.

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.

[tazva]

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.

[sonora]

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. https://github.com/osmandapp/Osmand/issues/3923#issuecomment-309232409 .

[tazva]

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.

[tazva]

I actually had a moment of surprise when the functionality remained intact yesterday for about 10 minutes before dropping out. No apparent reason why.

[tazva]

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.

[sonora]

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.

[tazva]

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" notifications@github.com 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 (@vshcherb 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 https://github.com/osmandapp/Osmand/issues/3898#issuecomment-313545948, or mute the thread https://github.com/notifications/unsubscribe-auth/AcPhMeNTHI0GpDeNpEEl1tuTB4xJqqDeks5sLWysgaJpZM4N1hnh .

[tazva]

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.

[tazva]

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.

[sonora]

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.

[sonora]

Hardy:

• Code ref to check: https://github.com/osmandapp/Osmand/blob/master/OsmAnd/src/net/osmand/plus/views/mapwidgets/MapInfoWidgetsFactory.java#L737
• Also: https://github.com/osmandapp/Osmand/commit/1c803c3e08714c4f20817f60cdba09ae337f12c2

[tazva]

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" notifications@github.com 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 https://github.com/osmandapp/Osmand/issues/3898#issuecomment-313850985, or mute the thread https://github.com/notifications/unsubscribe-auth/AcPhMWepgDjDtXlZtu5Wz8D3GVoCplkQks5sL2rkgaJpZM4N1hnh .

[sonora]

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!

[tazva]

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.

[sonora]

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.

[sonora]

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.

[sonora]

PS: Also related to https://github.com/osmandapp/Osmand/issues/2960#issuecomment-240542172. 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.

[tazva]

Yeah, those threads sound exactly like my issue.

On Jul 9, 2017 03:22, "Hardy" notifications@github.com wrote:

PS: Also related to #2960 (comment) https://github.com/osmandapp/Osmand/issues/2960#issuecomment-240542172. 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 https://github.com/osmandapp/Osmand/issues/3898#issuecomment-313903962, or mute the thread https://github.com/notifications/unsubscribe-auth/AcPhMVSY14Gkq6BTdQo6A6fTlYrHn8qDks5sMH-qgaJpZM4N1hnh .

[vshcherb]

@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.

[tazva]

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" notifications@github.com 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 https://github.com/osmandapp/Osmand/issues/3898#issuecomment-313968031, or mute the thread https://github.com/notifications/unsubscribe-auth/AcPhMSvmTELGH0HxKoqH_6ncHBCcPGOnks5sMUv0gaJpZM4N1hnh .

[sonora]

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.

[vshcherb]

For non-navigational case that's a known issue, it just jumps similar to how GPS jumps. So until we teach GPS signal to stay tuned or learn more about the history movement, it will be like this.

[tazva]

There's got to be a way around it. I find it odd to believe a dedicated 1.4ghz or 2.7 ghz system can't process lookups quick enough, especially since it worked fine for me for months with no other changes. It just seems odd. Lookups could be narrowed down in some fashion, it's not like I have a country's worth of maps downloaded, just one local map.

It seems to simply get stuck, taking hours to undo itself, sometimes never. That isn't a simple delay, that's the process getting lost.

On Jul 9, 2017 18:39, "vshcherb" notifications@github.com wrote:

For non-navigational case that's a known issue, it just jumps similar to how GPS jumps. So until we teach GPS signal to stay tuned or learn more about the history movement, it will be like this.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/osmandapp/Osmand/issues/3898#issuecomment-313970323, or mute the thread https://github.com/notifications/unsubscribe-auth/AcPhMQBnCsRynby5v3lXPU84R9qC24-Lks5sMVaLgaJpZM4N1hnh .

[sonora]

What really bothers me is the high CPU load during and after this occurs, this really needs fixing. It seems that OsmAnd keeps looking up the address but never finishes or times out, and this is really a CPU (and eventually battery) eater. I can even feel the difference in temperature of a device in my hand between when exhibiting the issue and when not.

[sonora]

I went through all the evidence again, and it looks to me like this: While moving without navigation but with the street name widget on, we queue an enormous number of reverse address lookups. Looks like during motion we hardly ever catch up again. That is also why CPU usage remains enormous even when you put OsmAnd in the background then. But when you stop and leave the device at rest for a (potentially very) long time, this eventually does catch up (until you start moving again).

Maybe the solution is as simple as not queuing any lookup processes (a new one always cancels an old one), or we somehow strictly limit the number of requests waiting for resolution? Or we find a way to flag requests as outdated, like all unresolved ones which were triggered by successive calls from/for the street name widget.

[tazva]

Your explanation matches my observation from yesterday. I ran OSM on my 4x2.7ghz device for a short while (10-15 minutes), and in that duration, it became very warm and killed off almost 30% of the battery. It continued to do so long after I'd stopped moving (but the street name never came back), so I had to kill the OSM process. This may also explain why OSM drains so much battery if I leave my tablet on but motionless, and the CPU never idles down.

In addition to the suggestions you've made, perhaps some sort of rate trigger could be included, based on the speed, because the faster you travel the greater the distance from your previous point. Perhaps all of these ideas could be put into a dev/beta menu, and could be toggled on/off to see what helps? I don't mind toggling my beta opt-in on if we can help work this out.

[scaidermern]

I've experienced several very long delays when adding OSM notes while moving. The note dialog opens up immediately, but after closing it it takes a very long time until OsmAnd shows the window where you can select to upload or delete the note, sometimes this takes 30 minutes or longer. Maybe this is caused by the same problem.

What is the reason for queuing reverse address lookups? Do we need older addresses at all?

[sonora]

To queue a small number probably makes sense, like for when you add several interim destinations or map markers in a row, you may want to see the address resolution for all of them, not just the last one. But it makes no sense if we clog the process by dozens of successive resolution requests as you move along segments of OSM ways.

[vshcherb]

It searches every 10-50 meters and that could be a problem (we could fix it)

if (loc == null || loc.getAccuracy() > 50) {
            return null;
        }
        if(last != null && last.distanceTo(loc) < 10) {
            return r;
        }
        if (r == null) {
            scheduleRouteSegmentFind(loc, true, null, null);
            return null;
        }
        double d = getOrthogonalDistance(r, loc);
        if (d > 15) {
            scheduleRouteSegmentFind(loc, true, null, null);
        }
        if (d < 70) {
            return r;
        }

[tazva]

I've had issues saving GPX files manually, where sometimes it wouldn't save at all, or it took what seemed like forever. Selecting 'save' just puts the word "SAVE" in the GPX widget, and the file is often not saved, is sometimes lost, and sometimes is saved days later. I'm wondering if the lag issue we're discussing is causing problems for the GPX saving? There's also times GPX doesn't reset to zero, even several days later, it just keeps building.

This guy had a similiar issue with failure to zero out upon saving: https://github.com/osmandapp/Osmand/issues/2479

[vshcherb]

The cpu usage is quite high mostly because no caching is use between interactions. Which could be a nice improvement.

[tazva]

I'm thinking this overhead issue is what's causing a cascade of other minor issues, such as my GPX file not "resetting" sometimes, and then for no apparent reason, resetting in the middle of a drive.

I also noticed on a couple of occasions where I was in navigation mode, it had to re-route, and re-routing was so slow that at one point, I pulled over and waited for 10 minutes while it continued to 'calculate'. i eventually just had to close the application and re-open it. Sometimes re-routing is instant, sometimes it takes 30 seconds or a minute, just for missing one turn, despite the streets all being parallel.

[tazva]

Here's a couple more data points.

I was in navigation mode the other day for about half an hour, and during this time the street name disappeared a handful of times. When it did, it never came back, but when I crossed onto the next set of directions/new street, that name would pop up. When the name disappeared, it left the directional icon up in the bar (so the left turn arrow for example). It didn't disappear a lot, but it was happening.

I notice that as it switches to night mode, it seems to be a very slow transition, particularly once the street name has disappeared (and we presume OSMA is backlogged). It slowly fills sections of the display with the night theme, sometimes takes 5 seconds, sometimes takes 20 seconds.

I'm presuming all of this to be due to the backlog issue we've discussed here. I'm using the most current version of OSMAnd+.

[tazva]

Adding to my comment above, in nav mode, it seemed less likely for the street name to disappear, whereas in non-nav mode, you can count on the name disappearing.

[tazva]

While in night-mode, I've noticed that as it transitions between various map levels, this transition can sometimes be 'slow' in drawing on screen. This results in patches of the map being shown in 'day' mode, which causes a 'bright white' flashing on screen (because the light map colors are contrasting fast with the dark map colors).

[scaidermern]

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.

[tazva]

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.

[tazva]

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.

[CJTmmr]

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. When somehow display is okay again CPU is back to normal. Some search proces gets probably in a endless loop.

[tazva]

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.

[tazva]

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: For visual monitoring, I have it set to 1s update intervals. For logging CPU load to a file, I had it set to 30s intervals (I forgot to set it to 10s). I've kept an eye on the overlay over the past week, and OSM+ cpu usage was much higher than I realized.. at idle it's burning up the CPU for no apparent reason. By idle, I mean just turning the tablet on and letting it sit motionless. GPS shows no movement, but OSM+ is typically loading the CPU 30-40% at idle.

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.

[tazva]

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).

[sonora]

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.