@Huibertus correct en tevens juist. Misschien dat het bij de nieuwe webplanner meegenomen gaat worden. Tot die tijd ff wegvegen

hi @m.-schrijver I would also like to mention this does seem very strange behaviour regarding online/offline, cell coverage etc I recently rode a multi-day tour in Ireland (9 days), and did not have any issues with regards to internet/cell coverage I use an oukitel RT3 rugged tablet that does not have a SIM card therefore no cell or internet access and everything is navigated offline. all maps are downloaded to the device and MRA is synced before leaving. not much help to you I'm sorry, but this may highlight that cell/internet should not have any bearing on navigation. ️

sorry @Hubert-Thoring the routing all seems to work perfectly with a 2 point route if it is a shorter distance WITHOUT changing any settings, just increasing the distance the routing calculator will suddenly start taking crazy detours this has nothing to do with motorway per-se, the motorways are just an simple repeatable way to demonstrate the issue & make it easy to see where the routing calculator goes wrong it is very simple for anyone to test, just create a 2 point route far enough apart & try to navigate it as a track offline for me the fact that these detours can occur points to a problem somewhere in the routing calculator / algorithm as it is very repeatable problem I would think it relatively simple to find the root cause fixing the root cause of this issue may also resolve other routing glitches of which we hear of many on this forum thanks for the reply

Ich würde kaufen, aber kein Abo nehmen. Ich brauche das zu wenig, deswegen warte ich auf ein Angebot. Das kriege ich, dauernd, aber nur für das Abo und nicht für Lifetime

@Mike-wiruth, I think you enabled some messy track to be visible on the map? Try this: On your phone, in the main map, press the map-style button. [image: 1785138114820-a010dd02-e51d-44ad-bc59-e3caa487c7a2-image.jpeg] Then tap the second menu option: "Routes visible on map" [image: 1785138183124-c36bc9cb-48ae-4d30-b144-351ba252e19b-image.jpeg] If any routes are listed here, delete them by the X on the right Or click the bin symbol to delete them all at once. [image: 1785138310954-8c62710a-5ac2-47a8-9601-1687bea86bb9-image.jpeg]

@Pierre-c would you possibly be able to share a route where you consistently get the added time & could you check if the distance is the same at the start of the navigation as is calculated on the web planner? I agree with what @nick-carthew is saying & this is how things should work MRA does behave as such most of the time but occasionally it has glitches or edge cases so it would be good/helpful if someone could check your route

That´s why pictures help.

AA and ACP are an extra layer of complexity but they are certainly not the cause of most problems.

Because some apps can run in the background and are not really active on that moment.

Last route is last route edited in app or web page.

I honestly can't tell you why it happened, but I can assure you I didn't accidentally disconnect... the same thing happened when the ability to automatically deactivate additional devices was implemented (if I remember correctly)... but I remember it was a normal thing... here it even synchronized my entire route database from scratch...

@ErikMatthezing The irony is that if you use Google Maps or Apple Maps, you wouldn't think (I certainly wouldn't) to verify the map against HERE, OSM, TomTom, etc. You accept the map/route is accurate and go on with your life. Somehow, we've come to believe that a checklist item in using HERE is to compare it against others maps for accuracy for everyday use. It's reality. At the same time, it's not ideal, but an aspect of MRA that all users should understand.

The same thing happened to me but on mobile devices, both iPhone and iPad, but it seems to me that if I put Google on top, this is what I think the problem is, the map doesn't respond correctly, as if the software needed more resources for a stretch and the processor couldn't handle it, then if I change the map and put MICHELIN for example, everything goes back to normal... it's been happening for a few weeks now, I even wrote about it somewhere, but it seems to me that it wasn't given too much importance... I thought it was just my problem... but apparently that's not the case...

@corjan-meijerink : any News about this Problem?

@RetiredWingMan

In settings and then audio , you can (second from the bottom) what next will speak out . Check the box all.

@Brian-McG @brian-mcg You're right. This has nothing directly to do with transferring files other than it being one of the pieces that ensure Zumos operate correctly as navigation devices. If that doesn't interest you, so be it. BTW, Garmin GPS routing algorithms have changed over the years, pre-Zumo you could take a Basecamp route calculation to the bank in that it would 100% match when recalculated in the Garmin GPS. That's no longer the case. I'm surprised you didn't know this given your "mult-multi years" Garmin experience. To the topic, this discussion has everything to do with: The HERE map not placing the road where it actually is. The MRA app recognizing the map discrepancy, but the Web Routeplanner not showing any overt alert. Sync should actually mean Sync. The MRA "Skip Waypoints automatically" enabled not working in this scenario. I was able to dynamically enable the XT3 to successfully recalculate at WP#7, so what's with the blanket "advice not to enable the recalculate function is decades old"? Nothing is absolute, yet you're hanging your hat on it. Odd. I'm trying to be transparent and reasonable, and I can say with complete honestly that the XT3 worked better than the MRA app in successfully routing the section from WP#7 to WP#8. If this had not been a verification test, and I was just routing with the XT3 (forgetting the app), I probably wouldn't have known there was a problem at all. I would have been on the straighter section on top of the mountain ridge before being able to look down at the route, and I wouldn't have seen that the XT3 handled the situation without any intervention. Again, thank you for helping me unravel what happened. We obviously don't agree on some things, but I appreciate the input you provided.

Het is audiofunctie van je AA headunit. Bij schermen als Chigee wordt meestal de telefoon als basis voor de audio gebruikt. En die kent de scheiding niet. Tenzij MRA je de keuze gaat geven om MRA over een ander kanaal te laten afspelen dan het standaard mediakanaal. (Wellicht een idee voor een toekomstige update). De muziek wordt nu inderdaad wat gedimd. Maar bij een echte scheiding zoals AA dat kan, kan je gewoon voor 2 verschillende volume niveaus kiezen. Je muziek relatief zacht en je navigatie juist vrij luid, of wat je voorkeur ook is. Waarbij het navigatiekanaal altijd voorrang heeft op het mediakanaal. Als het ik me goed herinner, wordt de muziek niet gedimd maar volledig stil gelegd. Bij mijn Goldwing kan ik er zelfs nog voor kiezen om de Google assistant ook een eigen volumeniveau mee te geven.

Here is a new update on that problem. Yesterday, i had that same problem again. I then closed the app on my iPhone and start it directly on the Chigee. From there, i was able to start last route and it displayed instantly. Any idea about a real solution ? Thanks