inis zerschossen (Danke Navigon )

Folgendes simple Experiment: (MN4.2 auf SD installiert.)
SD auf Write-Protect schalten. MN4 starten,
_nur_ eine Karte ansehen, 1..2-mal Zoom in/out
und wieder ausschalten.
Ergebnis:
- während des Laufs wird 1-mal die navlib gespeichert.
(im Hauptspeicher unter proDBxxx.tmp)
- nach Beendigung wird gespeichert:
. prefs.ini sowie navlib nochmal (Form proDBxxx.tmp)
. man beachte die Zeitmarken dieser Files.
- Beenden dauert ca 2..3 Sek, gegenüber 20..30 sonst.

Das klingt alles sehr plausibel und nachvollziehbar,
nur das Beenden _mit Schreiben_ auf SD dauert eine Zehnerpotenz mehr.
Warum?????
(Dieser Effekt ist in ähnlicher Form seit mind MNEE vorhanden,
ev. sind auch zusätzliche inis betroffen)

Das Schreiben der 3 Files auf die SD (wieder freigegeben)
dauert übrigens max 4 Sek.

Wolf
...
Dieser Glitch/diese Macke ist _sehr eigenartig_.

Ich könnte jetzt mal in die Sourcen des SD bzw. ATA Treibers schauen. Dazu habe ich heute aber wirklich keine Lust mehr.

Aber Beenden mit 20-30 Sekunden? Das kann ich an keinem meiner PPC beobachten egal ob mit oder ohne Schreibschutz, die angegeben 3-4 Sekunden könnten hinkommen.

Zitat

Aber Beenden mit 20-30 Sekunden? Das kann ich an keinem meiner PPC beobachten, die angegeben 3-4 Sekunden könnten hinkommen.

Dann bin ich wohl der einzige, oder?
In den Sourcen der Treiber zu wühlen bringt es nicht, das Schreiben ist Ok,
aber MN "wühlt" am Ende noch ziemlich (+-85% CPU für deutlich 2-stellige Sekunden) herum.
Wolf

Zitat

Original von DeJe
Aber Beenden mit 20-30 Sekunden? Das kann ich an keinem meiner PPC beobachten egal ob mit oder ohne Schreibschutz, die angegeben 3-4 Sekunden könnten hinkommen.

Da darf ich dann also mal wieder auf diesen Thread verweisen: http://www.pocketnavigation.bi…thread.php?threadid=29276

Das Problem der zerschossenen INIs ist doch ziemlich Navigon-gemacht. Es wird beim Beenden des Programms die prefs.ini und navlib.ini nicht einfach nur einmal gespeichert, sondern 8 mal (prefs.ini) bzw. 6 mal (navlib.ini) geschrieben. Noch weniger nachvollziehbar ist, dass bei jedem Start die spgps.ini zig-mal geschrieben wird.

Daraus resultieren bei Installation des MN4 auf SD-Karten mit schlechter Schreib-Performance die langen Start- und Beendigungszeiten.

DeJe hat ja an anderer Stelle schon ein sehr nützliches Tool ("StartNavi") bereitgestellt, das während der Ausführung von MN4 die INIs mit Schreibschutz versieht und danach das Attribut wieder auf beschreibbar setzt. Wer bereits seine richtigen MN4-Einstellungen gefunden hat, kann damit sehr wirkungsvoll den zerschossenen INIs vorbeugen und gleichzeitig den Programmstart und das Beenden (abhängig von der Performance der Speicherkarte) noch beschleunigen. Das Tool findet ihr unter http://www.pocketnavigation.bi…?postid=326897#post326897.

Zitat

Original von jenki
NAVIGON empfiehlt, die Installation NICHT auf einer Speicherkarte durchzuführen, da dadurch beim Speichern der notwendigen Dateien eventuell nicht genügend Zeit zur Verfügung steht, falls der PDA in diesem Moment ausgeschaltet wird."

Hat Navigon gepostet, steht in der FAQ, sollte eigentlich jeder wissen. Wer diesen Rat nicht befolgt, muss auch mit sowas rechnen. Wer ohne Not nicht im Hauptspeicher installiert, sollte sich bewusst sein, dass er völlig unnötig solche Probleme riskiert. Bei PDAs mit 64 MB sollte es wirklich keine Probleme geben, für MN|4 den Hauptspeicher zu nutzen. Ich kann es nur immer wieder empfehlen.

Zitat

Original von tpmjg
DeJe hat ja an anderer Stelle schon ein sehr nützliches Tool ("StartNavi") bereitgestellt, .....http://www.pocketnavigation.bi…?postid=326897#post326897.

na endlich kommt dieser Hinweis, der DANK DEJE die Lösung schon seit Tagen bereit hält

Das ist richtig, die Ursache liegt in der Programmierung bei Navigon, warum da so viele Zugriffe notwendig sein müssen, ist wirklich nicht nachvollziehbar.

Wichtig ist, dass man die Lösung kennt.

1. Installation im Hauptspeicher, sofern genügend davon vorhanden ist. Dann gibt es keine Probleme.

2. Oder man nimmt das Starttool von DeJe. Sehr praktisch.

"Wichtig ist, dass man die Lösung kennt."

komisch und ich hätte gedacht, wichtig wäre es, wenn das problem im programm behoben werden würde. dann müsste nämlich niemand mehr "die lösung" kennen. aber das ist sicherlich der völlig falsche ansatz? die alten mn versionen waren sicherlich einfach so schlecht programmiert, dass sie diese schwierigkeiten in dem maße (bei der installation auf speicherkarte) noch gar nicht hatten. alles neu macht der mai

--
highend

@ All,
nur mal ne Anmerkung dazu, ich hatte jetzt eine Woche die Gelegenheit den Desti 3.065 mal auszutesten, der macht es auch nicht besser, selbst im Ram (anscheinend der einzige mögliche Installationsort!) dauert es ca 3-5 Sek. bis der Speicher wieder freigegeben wird (bei mir braucht der MN|4.01 auf SD-Karte ca 5-7 Sek.!), er scheint auch noch etwas zuschreiben.
MfG
Olaf

Zitat

Original von highend
"Wichtig ist, dass man die Lösung kennt."

komisch und ich hätte gedacht, wichtig wäre es, wenn das problem im programm behoben werden würde. dann müsste nämlich niemand mehr "die lösung" kennen. aber das ist sicherlich der völlig falsche ansatz?

Das ist der falsche Ansatz. Und zwar für den User hier! Und da wir ein Userforum sind, in dem es in aller erster Linie um Lösungen für User geht, ist hier nur wichtig, diese Lösungen zu kennen.

Und für Navigon ist allein der richtige Ansatz, das Problem im Programm zu beheben, so gesehen gebe ich Dir natürlich völlig Recht. Und ich bin mir sicher, dass das Problem bei Navigon schon bekannt ist. Da wir aber nun nicht Navigon sind, können wir es selbst nicht beheben. Wir können nur dem User helfen, alles andere kann nur Navigon.

Wenn ich also so einen Satz schreibe, tue ich dies natürlich immer nur aus Sicht des Userforums. Und aus Sicht des Users, der schnelle Hilfe benötigt. Und da ist eben allein wichtig, dass er schnelle Hilfe bekommt, indem er die schnelle Lösung kennt.

tower, das was du hier beschreibst, ist _lediglich_ eines: (neudeutsch) ein workaround für den/die fehler, den/die navigon zu vertreten hat.

nothing more, nothing less.

--
highend

Zitat

tower, das was du hier beschreibst, ist _lediglich_ eines: (neudeutsch) ein workaround...

Highend, deine Lösung ebenfalls! Navigon würde ein work around programmieren für einen Fehler im Betriebssystem. Wo ist der Unterschied?

Zitat

... für den/die fehler, den/die navigon zu vertreten hat...

Du behauptest hier Dinge (Navigon würde diesen Fehler zu vertreten haben) die nicht haltbar sind!

Noch einmal die Frage:
Wenn ich Daten schreibe, egal wie viele oder wie lange oder aus welchen Gründen auch immer und das Betriebssystem schaltet den PPC ab ohne Rüchsicht darauf und ohne diese Daten zu retten. Wessen Fehler ist das?

Es bringt mir als Nutzer des Forums nichts, stets mit dem Finger auf Navigon zu zeigen. Alle mir bekannten Software-Produkte haben ihre Schwächen.

Ich bin froh über jedes Forum, dass mir Hinweise gibt, wie ich dies Schwächen umgehen kann!

FSNAVI

Och Leute,
wir sind doch hier nicht beim hohen Gericht.:§$%

Laßt uns doch einfach weierhin gegenseitig Hilfestellung leisten, und dann ist es OK.

Mir wurde hier jedenfalls prima geholfen, egal, wer schuld ist
Bill oder Onkel Navigon.