Ich hatte so etwas zumindest einmal, als ich schlechtes Internet (also nur so ein bisschen) hatte. Kannst Du Dich daran erinnern, wie der Empfang bei Dir war, als bzw. bevor es auftrat?
1 Like
@boldtrn das klingt ähnlich wie das Problem, das ich mit AA hatte. “On-route” Erkennung nach der Neuberechnung.
1 Like
Das trat sicher über ne halbe Stunde lang auf. Glaub nicht dass da immer schlechter Empfang war. Aber das hab ich nicht beobachtet. Aber er hat ja immer gerechnet. Blaue Linie ging immer ab dem “Neu Berechnen” Punkt. Aber der Button “Neu berechnen” kam gleich wieder.
1 Like
Hast du vor diesem Verhalten evtl eine andere Funktion benutzt, die eine Neuberechnung ausgelöst hat? Zum Beispiel Straßensperrung oder Tankstellensuche. Bei mir sind ähnliche Probleme in Zusammenhang mit der Straßensperrung aufgetreten, allerdings nur wenn Android Auto verbunden war.
Ich bin sehr viel neben der Route gefahren. Ich hatte einen Zielpunkt, bin aber hinter einem Kumpel hergefahren, der eine ganz andere Route gefahren ist. Hab dann ab und an einen Weg zum Ziel manuell berechnen wollen. Das ging dann nicht richtig. Naviation beenden und neu starten ging. Aber danach hatte ich das Phänomen wieder.
1 Like
Hast du auch viele WPs auf der Route gehabt, die du manuell überspringen müsstest?
Falls dies wieder passiert, du könntest versuchen eine Strassensperrung zu setzen und schauen wo die entsprechende rote Linie angezeigt wird. In meinem Fall hat sich die entlang der ursprünglicher Route und nicht der neu berechneten bewegt. Die App arbeitet offensichtlich mit zwei unterschiedlichen Datensätzen für die Anzeige auf dem Bildschirm und für andere Funktionen. Warum die App durcheinander kommt - müssten die Entwickler herausfinden.
Das ist übrigens nicht so, ich vermute das Problem, welches du beschrieben hast wo anders. Wäre natürlich schön gewesen wenn es ein AA exklusives Problem ist. Bzw. eventuell war das hier auch nochmal etwas ganz anderes.
1 Like
Ok, vielleicht ist das nicht so gewollt, aber offensichtlich existieren zwei unterschiedliche Datensätze. Hier ist der umgekehrte Fall, der für mich dies deutlich macht. Ich lasse die App die Route neu berechnen, bleibe aber auf der ursprünglich geplanten Route:
- Die Funktion die erkennt, dass ich auf der Route bin und die Abbiegehinweise ausgibt, arbeitet offensichtlich mit einem Datensatz (alte Route)
- Die Funktion mit der die blaue Linie gezeichnet wird arbeitet mit einem anderen Datensatz (neue Route).
Das ist eigentlich der gleiche Fall mit der Straßensperrung, den ich bereits in dem anderen Post beschrieben habe, nur in diesem Fall bin ich auf der ursprünglichen Route geblieben.
Also haste das komische Verhalten in Android Auto oder aufm Handy Display?
Oder beides?
Ich kann das Verhalten aktuell nur mit Verbundenem AA reproduzierbar triggern, dann ist es aber sowohl auf dem AA, als auch auf dem Handy vorhanden.
Ich habe direkt hintereinander an der gleichen Stelle mit App-Neustart zwischen den Versuchen probiert - ohne AA konnte ich das Verhalten nicht triggern.
Die Symptome sind wie folgt:
- Die App erkennt nach einer Neuberechnung nicht, dass ich auf der blauen Linie (“on-Route”) bin. Eine erneuerte Neuberechnung generiert erwartungsgemäß einen neuen Startpunkt und neue Route, wird aber immer noch nicht als “on-Route” erkannt. Dies stimmt scheinbar mit dem überein, was @schippy beschrieben hat.
- Wenn ich aber vom identischen Ausgangspunkt (Fehler getriggert) auf der original geplanten, aber nicht mehr mit der blauen Linie markierten Route bleibe, dann läuft die Navigation weiter bzw die Abbiegehinweise werden angezeigt wie ursprunglich geplant. In einem Screenshot oben ist sogar der weße Pfeil auf der Straße zu sehen, obwohl die blaue Linie woanders ist. Dieses zweite Symptom werden die meisten User so nicht erleben, weil sie in einem Realfall schon von der Originalroute abgekommen sind. Dies kann nur mit einem gezielten Test reproduziert werden - dafür muss sich aber der User noch erinnern, wo die Originalroute ursprunglich war um wieder drauf zu kommen. Das ist mMn für einen normalen User meistens zu viel gefragt.
Ich habe da einige Stunden investiert um den Trigger mit AA herauszufinden und hoffe, dass es bald gefixt werden kann, weil es reproduzierbar ist. Wenn das gleiche Verhalten von anderen Triggern auch ausgelöst werden kann dann liegt der “root-cause” vermutlich nicht direkt in dem Trigger, den ich gefunden habe, sondern irgendwo in der SW-Archutektur oder in einer fehlerhaften SW-Komponente, die mehrere korrekte Inputs fehlerhaft behandelt. Oder aber, es sind tatsächlich komplett unterschiedliche Fehler mit den gleichen Auswirkungen.
1 Like
vlt sollte man es in dem AnroidAuto feedback thread posten
1 Like
Dieser Bug passiert fast bei jeder Fahrt bei mir.
Es hat auf jeden Fall was mit dem Aus- und Einschalten des Displays zu tun.
Es wär toll, wenn ihr nen Switch einbaut, dass den Usern eine Wahl zwischen den neuen und der alten Zoom-Methoden erlaubt .
Ich hatte nie Probleme mit dem alten Zoomverhalten.
Und das neue scheint eine Verschlechtbesserung zu sein:(
1 Like
Und heute hatte ich das hier:
Hab während der Fahrt gemerkt, dass der Navpfeil springt und nicht “fährt”.
Als ich screengrab gestartet habe, ist es nicht mehr gesprungen, sondern komplett gefroren.
Aber die Sprachansagen kamen immer noch rechtzeitig!
Hab dann angehalten, pausiert und wieder gestartet. der Bug war weg.
Man könnte sagen, der GNSS Empfang war verloren. Ist aber nicht so:
- Warum zeigte dann Kurviger 98kmh Geschwindigkeit an?
- Warum hat Pausieren und Starten der Navigation denn geholfen?
- Ich habe in meinem Google Timeline nachgeschaut. da gabs die Lücke nicht!
- Und die Sprachansagen kamen richtig an
1 Like
Wir wissen mittlerweile woran dieser Fehler liegt. Das ist leider ein Bug in unserer Kartenengine. Wir werden diesen vermutlich mit dem nächsten Update beheben können, das sollte kein dauerhaftes Problem sein.
Genau, der Fehler sollte nicht am GPS liegen (oder z.M. nicht nur). Wir haben diesen Fehler immer mal berichtet bekommen. Aktuell wissen wir noch nicht woran das liegt.
2 Likes