Version: unspecified OS: Linux Marble 1.0.1 on Maemo. I have pre-downloaded OpenStreetMap tiles and using offline routing. Marble is in offline mode. When I select points for "Direction from here" and "Direction to here", Marble shows the route without problem. But when I switch to directing/routing mode (green icon) it starts asking for connection from time to time - and when it starts asking, it is 6 times or so just one ask after another - very annoing to touch it so many times when driving... Reproducible: Always
I'm aware of two points where the 'work offline' setting is ignored: - In the 'Add bookmark' dialog, which must be invoked manually however - When the GPS position is lost and the N900 tries to use AGPS The latter only pops up once though, so I'm a bit confused what could cause several connection tries. Even when tiles are missing you don't get a connection attempt in offline mode. Several connection attempts in a row only happened to me when Marble was not set to offline mode so far.
Is there any logging/debugging mode for N900 that I can see where the connection request came from? Even Marble's or Maemo's? (I will also try to disable AGPS and test again...)
Ahh, I found another possible reason (which would be my fault): I have not only enabled Monav, but also OpenRouteService and "Yours". So probably these backends tried to recalculate way during routing?
After disabling all other routing backends, it only asks once because of - as you noted - AGPS. After disabling AGPS, it never asks to connect. So I am closing this as invalid. It was my fault.
Git commit 1396e2163c736e186004633c7dc0c7aeafe9efc2 by Dennis Nienhüser. Committed on 06/04/2011 at 22:33. Pushed by nienhueser into branch 'marble-1.1'. Fix routing manager not always being aware of offline mode on Maemo. The routing manager was informed about offline mode indirectly through the routing widget. The latter is created lazily on Maemo, so the routing manager was not aware of offline mode if it was enabled before opening the routing widget for the first time. BUG: 270043 (cherry picked from commit 0f4730f395219b2b4129f70f195a66a97b88f18f) M +1 -0 src/lib/MarbleControlBox.cpp http://commits.kde.org/marble/1396e2163c736e186004633c7dc0c7aeafe9efc2
Git commit 0f4730f395219b2b4129f70f195a66a97b88f18f by Dennis Nienhüser. Committed on 06/04/2011 at 22:33. Pushed by nienhueser into branch 'master'. Fix routing manager not always being aware of offline mode on Maemo. The routing manager was informed about offline mode indirectly through the routing widget. The latter is created lazily on Maemo, so the routing manager was not aware of offline mode if it was enabled before opening the routing widget for the first time. BUG: 270043 M +1 -0 src/lib/MarbleControlBox.cpp http://commits.kde.org/marble/0f4730f395219b2b4129f70f195a66a97b88f18f
Marble should be smart enough to handle that situation: Even when an online routing backend is enabled in the profile it shouldn't be used in offline mode. It's not too easy to reproduce the problem, but I think that I found the reason and hope that the commits above fix it. A workaround for the current version should be to open the routing dialog once and switch to offline mode afterwards. Afterwards the offline mode should be propagated correctly to the guidance mode. In Marble 1.1 and later that workaround won't be needed of course. Regard logging: You can start marble from a terminal (e.g. X Terminal) via /opt/marble/bin/marble.sh --debug-info to get debug message printed to the terminal. Not everything is logged of course.
Does this resolution mean that when I get this issue live and well with 1.1.1, it could be caused by AGPS (which I had switched on) and I should complain at bugs.maemo.org? Once it decides it wants connect Internet it looks it is not possible to switch it off. Certainly it asks more than once for the connection. In the end I gave up and connected via GPRS and I hope it won't cost me arm and leg. Quite certainly really offline mode would be very very welcome.
The AGPS behavior of Maemo to request a network connection is correct. You can cancel that connection request however (it should not pop up more than once every ~30 seconds while searching for satellites). I am aware of the following points where Marble tries to open a network connection in offline mode: - In interactive dialogs (monav configuration dialog, add bookmark dialog). This is intentional - When GPS is enabled and no satellites are in view. I opted for AGPS here because when a network connection is available the position will be found much earlier Now I'm not too happy with the solution yet since the popups due to AGPS, though happening rarely, are still annoying. I plan to change it such that in the future Marble determines whether a network connection is in place and starts GPS then with or without AGPS. This should lead to fast position finding when a network connection is available but still no popups when no is available. @Matej: I'll reopen this bug, there shouldn't be several connection attempts in a row in offline mode. I can't reproduce this so far however.
Git commit 39f9b74feff1094819a728cc2a7691b321cf8a1b by Thibaut Gridel. Committed on 03/02/2012 at 21:10. Pushed by tgridel into branch 'master'. DownloadManager: purge current tasks when going offline REVIEW: 103853 M +18 -0 src/lib/DownloadQueueSet.cpp M +1 -0 src/lib/DownloadQueueSet.h M +6 -0 src/lib/HttpDownloadManager.cpp M +1 -14 src/lib/TileLoader.cpp M +0 -4 src/lib/TileLoader.h http://commits.kde.org/marble/39f9b74feff1094819a728cc2a7691b321cf8a1b
Git commit bd156cae5b24782ddbf39f485193ee93be2504db by Dennis Nienhüser, on behalf of Thibaut Gridel. Committed on 03/02/2012 at 21:10. Pushed by nienhueser into branch 'Touch/1.3'. DownloadManager: purge current tasks when going offline REVIEW: 103853 (cherry picked from commit 39f9b74feff1094819a728cc2a7691b321cf8a1b) M +18 -0 src/lib/DownloadQueueSet.cpp M +1 -0 src/lib/DownloadQueueSet.h M +6 -0 src/lib/HttpDownloadManager.cpp M +1 -14 src/lib/TileLoader.cpp M +0 -4 src/lib/TileLoader.h http://commits.kde.org/marble/bd156cae5b24782ddbf39f485193ee93be2504db
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Seems that it actually got fixed eventually back then.