@mdx and @lubos: I mentioned the issue with the speed limit setting set incorrectly on the motorway in England. That started with this post in this thread and subsequently a few others, also by @jd417
Could this incorrect speed setting on the display have anything to do with this "urban speed trigger" instead of (gles) rendering? So that in my mentioned case MNF did not detect that I have left the city (urban speed)?
MFN now starts on my ASUS K004 with hardware rendering as exspected and I am now "on the road" (see above post, where I was in the wild). But a simulation crashes after one to two kilometers on a trip of 481 km whereas I stopped simulation of the same trip on software mode after about 20km because it ran without any problems until then.
On my Xperia Active street names are too small to read on hardware rendering.
Today I used the GLES version again in hardware mode on a 157 km trip. It didn't crash, but it "stuttered" 3 times.
Normally when driving you see the map progress with little steps. Today 3 times it "stuttered". It progresses, jumps back, progresses again, jumps back and that 10-15 times after each other (best guess. I had to pay attention to the road with dense traffic). After this 10-15 forward-backward hitches it suddenly jumps 100-200 meters (or so) further and continues where my gps position is at that time. As mentioned: it did that 3 times within 10 minutes on a trip of about 1 hr 40 min. I never had that in software mode.
Edit: I remember that I had this in earliers versions as well.
I've also experienced this. The navigation cursor changes to 4 grey arrows from the usual single red arrow (I think to indicate loss of GPS) & the map "freezes". After 5 - 10 seconds the red arrow re-appears & the map jumps to the current position. I believe this was mentioned earlier in this post.
As for the earlier crashes I reported I installed GLES 2.0.13+ from google apps testing onto a Sony Xperia Z3 compact & to date no crashes in hardware render. I've yet to try this version on the Moto G but I'll report when I get a chance.
Although street names are flashing on hardware rendering, while there are shown constantly on software rendering on my Xperia Active.
Interestingly hardware rendering seem to be much more stable on my old Xperia Active rather than on my (in comparison to the Xperia Active) more modern Asus tablet K004.
One question for @mdx Why android project was removed from crowdin? I think that if project is more available, than translations will have more time for fixes.
first thanks Natalie we did look at crowdin and there was some activity at the beginning, but after that it died off we are examining other possibilities
@tomas There is no activity because probably no one knows about it. I found information about translations by chance in this topic. Shame that currently I cannot correct some text after first android alpha release.
please understand that crowdin is not free we looked at activity and, considering price, it was decided that it was not worth the price we are looking at alternatives please note that we all appreciate your help
08-21 09:03:12.561 E/AndroidRuntime(20420): FATAL EXCEPTION: main 08-21 09:03:12.561 E/AndroidRuntime(20420): java.lang.NoSuchMethodError: android.widget.ImageView.setX 08-21 09:03:12.561 E/AndroidRuntime(20420): at com.mapfactor.navigator.map.MapFragment$1.onSingleTapConfirmed(MapFragment.java:214) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.view.GestureDetector$GestureHandler.handleMessage(GestureDetector.java:271) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.os.Handler.dispatchMessage(Handler.java:99) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.os.Looper.loop(Looper.java:130) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.app.ActivityThread.main(ActivityThread.java:3806) 08-21 09:03:12.561 E/AndroidRuntime(20420): at java.lang.reflect.Method.invokeNative(Native Method) 08-21 09:03:12.561 E/AndroidRuntime(20420): at java.lang.reflect.Method.invoke(Method.java:507) 08-21 09:03:12.561 E/AndroidRuntime(20420): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839) 08-21 09:03:12.561 E/AndroidRuntime(20420): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597) 08-21 09:03:12.561 E/AndroidRuntime(20420): at dalvik.system.NativeStart.main(Native Method) 08-21 09:03:12.595 W/ActivityManager( 8694): Force finishing activity com.mapfactor.navigator/.map.MapActivity
also I see some error message in log (not related to crash)
08-21 09:20:33.640 I/dalvikvm( 2304): Failed resolving Lcom/mapfactor/navigator/NavigatorApplication$MpfcActivityLifecycleCallbacks; interface 22 'Landroid/app/Application$ActivityLifecycleCallbacks;' 08-21 09:20:33.640 W/dalvikvm( 2304): Link of class 'Lcom/mapfactor/navigator/NavigatorApplication$MpfcActivityLifecycleCallbacks;' failed 08-21 09:20:33.640 E/dalvikvm( 2304): Could not find class 'com.mapfactor.navigator.NavigatorApplication$MpfcActivityLifecycleCallbacks', referenced from method com.mapfactor.navigator.NavigatorApplication.onCreate
Some points of my productiv testing of hardware renderer on my Xperia Active (ICS).
A couple of days ago I had sound output at the speeker of the device as well as on the car audio connected via bluetooth, while the car audio was approx. one second behind the speaker ...
Reaction to tapping the screen or hardware (volume) buttons takes often many seconds (this may be due to the old hardware of the phone).
Hardware renderings look is nice (beginning with the more modern position arrow), I like it much more than the software rendering. On the other hand look should not do it over functionality.
Crossing streets are shown the same way as the street is shown on which I am driving. If the street name is set to a crossing, I do not know, if the name shows to the crossing street or the street I am on. May be MFN could indicate crossing streets within arrows as <streetname> and not |streetname|.
Hi Dmytrio and hvdwolf, thanks for reports - the easy one should be fixed. It is hard to say if "playing with icon zoom levels" is related to memory, imports, or some other bug :(. In meantime there is version 2.0.21: - fixed show route on map from itinerary - fixed toolbar timing for click on map - other bugfixes thanks Martin
logcat has stacktrace of C++ crashes(this is missing in navigator logs because it needs extra permissions). Logcat has same level as debug level in navigator settings. I personaly prefer reading our logs on high level(there are missing important things on medium level)
Up to now I‘ve tested the GLES-version with a Nexus 7, today I tried it the first time with a Moto G (4,5"). After a short while I switched to software rendering mode because I could hardly see the highlighted route. The route is too small / too narrow for me or too far zoomed out, especially in areas with buildings ot lots of roads. Configurable zoomfactors as suggested by hvdwolf could be a good way to handle different tastes.
The speed limit symbol even on the smalI 4,5“ display is in a perfect size now, but I am having difficulties reading the displayed informations like distance to next event, speed info etc, no matter which rendering method (no problem on Nexus 7).
I had a terrible navigation last weekend with hardware rendering on my Xperia Active (with ICS). I just wanted to travel to a village near Zschopau, which is about 17 km from Chemnitz. The map zoomed out and out and out, so there was Chomutov at one point indicated on the map, which is approx. 60 km away beeline and at a second point, there was Usti nad Labem indicated, which is approx. 80 km beeline. The full route was compressed to a couple of millimeters length on normal navigation view (not tapping show the full route on the display). Every tap on the screen took approx. 30 seconds to be answered from the phone.
A day or two later I navigated with the next GLES version (I think that was 2.x.20) and problems seemed to be gone.
Navigator 2.00.21 on my Asus K004 still crashes after less than one km simulation with hardware rendering. Simulation seems okay on software rendering on the same device though (I did not check to the finish, just stopped simulation after a couple of minutes).
Road before turn has turn:lanes="left|left;through|through|right" and if you want to turn left Navigator suggests "left;through" and "trough" lanes however correct lanes are "left" and "left;through". The reason of issue is road on which you cannot drive, because it is opposite lane. That is should be considered by Navigator.
This is a very long running bug by now. MNF does indeed not consider "separate roads". In all of these cases MNF wants you to go straight on and then (almost immediately) go left.
I assume in left-driving countries it is the opposite way. I can't remember I noticed that last holiday.
Fix should be easy. When Lane Assistance determines lanes, it should discard lanes which are forbidden by Turn restrictions or have opposite direction.
Also road with "turn:lanes" tag can be split into several parts (like in the case I provided).
I agree with you that "it should be easy" :) , but I'm not a programmer. What seems easy for the non-programmer, might not be so easy for the programmer.
Is there a relation between the split roads?
How far are they apart? does 30 meter means that it is a totally different road, like you have in cities?
The fact that some other nav apps do it correctly, means that is is solvable.