Offener Brief, letzter Versuch

@tpmjg

Zitat

OK, Du "hättest es gerne" und ich auch, aber ich sprach davon, ob es für ein befriedigendes Navigationsergebnis erforderlich ist, ob man es also wirklich BRAUCHT. Wer dies als zugesicherte Eigenschaft betrachtet und darauf beharrt, kann dies gerne entsprechend reklamieren.

das wollte ich doch auch noch mal kommentieren... ob es jemand "braucht" ist völlig nebensächlich. man hat für diese funktion geld bezahlt. da wird man logischerweise ein anrecht darauf haben, dass es auch einwandfrei läuft. die chance zum nachbessern hatte navigon (5 monate lang). was daraus geworden ist, kann man ja bei den ganzen beschwerdethreads sehen (und das bezieht sich durchaus jetzt nur auf dieses "feature").

reklamieren? ja, das kann man. nur: wen kümmerts? navigon hat es offensichtlich nicht gekümmert. das ist übrigens auch der grund, warum ich diesen brief nicht unterschreiben würde. es hat (leider) einfach keinen sinn. ein "leserbrief" (ich denke nicht, dass es als viel mehr von zeitschriften, die auch tests veröffentlichen, angesehen werden würde, auch wenn da hunderte von unterschriften drunter stehen) wird da auch keine stellungnahme beeinflussen und ich glaube ehrlich gesagt auch nicht daran, dass er _wirkliche_ erwähnung in einem folgetest finden würde. eine beschwerde bei navigon? mit welchem ergebnis? hier wird sich täglich auch viele male beschwert, das hat nicht zu einer besseren _informations-_ oder _beschwerde-_ bearbeitungspolitk geführt (und das bezieht sich ausdrücklich nicht auf ch (und postings unter seinem namen)).

meine persönliche meinung, was passieren wird:

1. das problem wird bis zur nächsten version ausgesessen.
2. falls doch ein patch erscheinen sollte, wird er die bekannten probleme nicht ausmerzen. warum nicht? weil navigon diese probleme nicht nachvollziehen kann (aussage von ch). in diesem zusammenhang hätte ich mich ja gefragt, wo denn eigentlich die vor wochen angekündigten bögen von ch bleiben, die die fehlerbeschreibung bei navigon sinnvoll verwertbar machen lassen. aber das ist ein ganz anderes thema. 5 monate bis zum nächsten sp? tschuldige, wer wartet in der heutigen wirtschaft tatsächlich 10 monate auf eine wirklich funktionale version einer software? ich habe das warten schon lange aufgegeben.

--
highend

Zitat

Original von highend
...
es geht hier nicht um die read fehler die durch zu späte initialisierung der speicherkarte auftreten (und dafür ist die registry änderung da (obwohl sie auch nicht bei allen das problem behebt)). warum? ich sagte nicht umsonst, dass die testkarte ebenfalls im ram ist.
...

Ob der Read-Error und das Einfrieren durch exakt dieselbe Funktion innerhalb des MN4 ausgelöst werden, ist unklar. Zumindest behebt aber die Registry-Änderung i.allg. beide Phänomene.

Auch wenn Deine Testkarte im Hauptspeicher liegt, könnte es durchaus sein, dass MN4 beim Wiedereinschalten des Gerätes ein paar Programmfunktionen durchläuft, bei denen auch Zugriffe auf die Speicherkarte - aus welchen Gründen auch immer - durchlaufen werden. Hast Du tatsächlich und ernsthaft mit dem PNPUnloadDelay Wert experimentiert? Bei mir war bisher das Einfrieren z.b. erst ab einem Wert von 3500 zu beheben und jetzt mit meiner neuen Transcend 1GB SD Karte sogar erst mit 4000.

Im übrigen werde ich jetzt den Weg vieler anderer "Vorredner", die zu helfen versuchten, gehen und diesen Thread nicht mehr aufsuchen. Die Art des Umgangs miteinander ist hier einfach zu sehr polarisiert und zu unsachlich, auch wenn ich die Idee des offenen Briefes im Grunde gar nicht schlecht fand. Ich hoffe, sie wird, wenn es denn noch was wird, objektiv und sachlich genug umgesetzt.

Zitat

Auch wenn Deine Testkarte im Hauptspeicher liegt, könnte es durchaus sein, dass MN4 beim Wiedereinschalten des Gerätes ein paar Programmfunktionen durchläuft, bei denen auch Zugriffe auf die Speicherkarte - aus welchen Gründen auch immer - durchlaufen werden.

das entbehrt jetzt wirklich _jeder_ grundlage, so dass ich lieber keine weiteren kommentare dazu abgebe.

Zitat

Hast Du tatsächlich und ernsthaft mit dem PNPUnloadDelay Wert experimentiert?

nein, weil es für dieses szenario auch _völlig_ unnötig ist. es geht bei diesem parameter ausschließlich um die erhöhung des delays auf mountable blockdevices. dazu gehören logischerweise speicherkarten. aber nicht das interne ram des pdas.

"The PNPUnloadDelay subkey of the HKEY_LOCAL_MACHINE\System\StorageManager registry key specifies the time delay in milliseconds after the Storage Manager receives a Plug and Play (PnP) identifier unload notification of a block driver before it is actually unmounted. This notification forces unmounts of the partition driver and any file systems. During this period, the mount points move into a suspended state and requested I/O access to the mount points fail with ERROR_DEVICE_NOT_AVAILABLE. The primary use for this is during suspend/resume cycles where a block driver might unload and reload on resume. When the Storage Manager receives a load notification, it examines the block device to see if it is identical to the previously unmounted device. If it is identical, the block device remounts under the previous mount points. "

Zitat

Im übrigen werde ich jetzt den Weg vieler anderer "Vorredner", die zu helfen versuchten, gehen und diesen Thread nicht mehr aufsuchen. Die Art des Umgangs miteinander ist hier einfach zu sehr polarisiert und zu unsachlich

komisch, mir ist gar nicht aufgefallen, dass ich unsachlich geworden bin. zu helfen versuchen? durch pauschalisierungen im stile von: aber wenn du deine zeit mal nutzen würdest, deinen pda oder mn|4 zu optimieren, dann hättest du längst ein besser laufendes system? hier gibt es genügend leute mit problemen, die fachliche kompetenz mitbringen und trotzdem einzig mit mn|4 auf schwierigkeiten stoßen (die sich auch nach allen "optimierungsversuchen" nicht wegdiskutieren lassen)...

btw: bye (da du hier ja nicht mehr anwesend sein wirst).

--
highend

Zitat

Original von highend
meine persönliche meinung, was passieren wird:

1. das problem wird bis zur nächsten version ausgesessen.
2. falls doch ein patch erscheinen sollte, wird er die bekannten probleme nicht ausmerzen. warum nicht? weil navigon diese probleme nicht nachvollziehen kann (aussage von ch).

Also bei 1. bin ich mir auch mit jedem weiteren Tag sicherer. Ich glaube nicht mehr an einen weiteren Patch. Aber ich denke auch, es bedarf auch deutlich grundlegenderen Programmänderung, ein Patch allein würde die Probleme womöglich auch gar nicht beheben.

Auch wenn wir bei 2. im Ergebnis einer Meinung sind (wie gerade geschrieben). Dass Navigon die Probleme nicht nachvollziehen kann, glaube ich so nicht. Hat CH nicht nur gepostet, dass er sie auf seinem PDA nicht nachvollziehen kann? Aber Navigon ist ja weit größer und sein Aufgabengebiet wird vermutlich auch ein anderes sein. Ich hab noch nicht die Hoffnung verloren, dass Fehler gefunden und Performances verbessert werden, wenn auch wohl nur in der nächsten Version.

Zitat

Original von highend

das entbehrt jetzt wirklich _jeder_ grundlage, so dass ich lieber keine weiteren kommentare dazu abgebe.

nein, weil es für dieses szenario auch _völlig_ unnötig ist. es geht bei diesem parameter ausschließlich um die erhöhung des delays auf mountable blockdevices. dazu gehören logischerweise speicherkarten. aber nicht das interne ram des pdas.

Alles anzeigen

Dann werd ich wohl noch einmal wortbrüchig werden müssen und doch noch einen Kommentar abgeben.

MN4 zeigt an diversen Stellen ein Verhalten, das eigentlich zunächst "_jeder_ grundlage enbehrt", wie Du es so schön sagst. Oder wie erklärst Du Dir z.B. die vielen Schreibzugriffe auf die spgps.ini beim Starten des Programmes oder z.B. auch das unterschiedliche Routing-Verhalten der 2002er gegenüber der 2003er EXE oder die Tatsache, dass die mit Mapexport erzeugten Karten bei zwei verschiedenen Anwendern unterschiedlich sind, obwohl sie eigentlich den gleichen Ausschnitt (inklusive Einschränkung auf Ländergrenzen) exportiert haben. Logisch ist dies zunächst nicht zu erklären und trotzdem ist es so, weil da irgendetwas programmiert wurde, das man so eigentlich nicht erwarten würde. Am Ende hat es sicherlich doch eine erklärbare Ursache, denn zufällig unterschiedliches Verhalten habe ich bisher in der Computerwelt erst selten erlebt...

Beweise mir doch erst mal das Gegenteil, dass MN4 beim Wiedereinschalten nicht nicht irgendwelche Zugriffe auf die Speicherkarte macht - auch wenn eine Karte im RAM benutzt wird, bevor Du es so pauschal als unmöglich abtust. Genau diese Art von Suche nach Ursachen fernab des eigentlich normal zu erwartenden hat schon oftmals zu einer Problemlösung gefürt.

Hier von vornherein zu behaupten, dass diese Registry-Änderung bei Dir keine Abhilfe schafft, ohne es überhaupt probiert zu haben, nur weil Du es aufgrund des anderen Speicherortes Deiner Testkarte für ausgeschlossen hälst, ist eben genau das, was ich hier bemängele. Es werden Fehler moniert und als unbehebbarer Mangel dargestellt, obwohl es vielleicht doch eine - hier schon beschriebene - Lösung gibt.

Zitat

Original von tpmjg
MN4 zeigt an diversen Stellen ein Verhalten, das eigentlich zunächst "_jeder_ grundlage enbehrt", wie Du es so schön sagst. Oder wie erklärst Du Dir z.B. die vielen Schreibzugriffe auf die spgps.ini beim Starten des Programmes oder z.B. auch das unterschiedliche Routing-Verhalten der 2002er gegenüber der 2003er EXE oder die Tatsache, dass die mit Mapexport erzeugten Karten bei zwei verschiedenen Anwendern unterschiedlich sind, obwohl sie eigentlich den gleichen Ausschnitt (inklusive Einschränkung auf Ländergrenzen) exportiert haben. Logisch ist dies zunächst nicht zu erklären und trotzdem ist es so, weil da irgendetwas programmiert wurde, das man so eigentlich nicht erwarten würde.

Das stimmt allerdings unzweifelhaft. Und genau das macht leider auch das Helfen (und Geschwindigkeitsprofilfinden) so unglaublich schwierig.

Zitat

Oder wie erklärst Du Dir z.B. die vielen Schreibzugriffe auf die spgps.ini beim Starten des Programmes oder z.B. auch das unterschiedliche Routing-Verhalten der 2002er gegenüber der 2003er EXE oder die Tatsache, dass die mit Mapexport erzeugten Karten bei zwei verschiedenen Anwendern unterschiedlich sind, obwohl sie eigentlich den gleichen Ausschnitt (inklusive Einschränkung auf Ländergrenzen) exportiert haben. Logisch ist dies zunächst nicht zu erklären und trotzdem ist es so, weil da irgendetwas programmiert wurde, das man so eigentlich nicht erwarten würde. Am Ende hat es sicherlich doch eine erklärbare Ursache, denn zufällig unterschiedliches Verhalten habe ich bisher in der Computerwelt erst selten erlebt...

seit wann bin ich in der pflicht, das programmverhalten von mn|4 erklären zu müssen? das kann navigon doch selber nicht, oder hast du jemals eine erklärung dafür von offizieller seite gesehen, warum das routingverhalten der 2002 durchschnittlich besser ist als das der 2003 version? ich nicht. ich habs nicht programmiert, also wieso sollte ich es begründen können?

Zitat

Beweise mir doch erst mal das Gegenteil, dass MN4 beim Wiedereinschalten nicht nicht irgendwelche Zugriffe auf die Speicherkarte macht - auch wenn eine Karte im RAM benutzt wird, bevor Du es so pauschal als unmöglich abtust. Genau diese Art von Suche nach Ursachen fernab des eigentlich normal zu erwartenden hat schon oftmals zu einer Problemlösung gefürt.

? ich? du hast hier doch die behauptung aufgestellt, also beweise mir bitte, dass das der fall ist. oder läuft das jetzt so: ich stelle eine behauptung auf und du beweist mir, dass sie _nicht_ stimmt? was für ein verqueres denken ist das denn? das hat außerdem nichts mehr mit problemsuche zu tun, sondern mit kaffeesatzlesen oder orakel befragen.

Zitat

Hier von vornherein zu behaupten, dass diese Registry-Änderung bei Dir keine Abhilfe schafft, ohne es überhaupt probiert zu haben, nur weil Du es aufgrund des anderen Speicherortes Deiner Testkarte für ausgeschlossen hälst, ist eben genau das, was ich hier bemängele.

_das_ bemängelst du?? du beliebst zu scherzen. ich sage es für dich gerne nochmal: der registry eintrag ist für betriebssystemspezifische funktionen und nicht designed by navigon. bevor _du_ mir nicht stichhaltig beweisen kannst, dass deine _spekulation_ stimmt, muss ich da überhaupt nichts prüfen. falls du es vergessen hast, für viele (mit diesem problem (und bei diesen hat es _ausschließlich_ mit speicherkarten zu tun)), hat die erhöhung des delays keine abhilfe geschaffen. nachzulesen im entsprechenden PNPUnloadDelay thread). ist also sehr einfach: liefere den beweis dafür, dass mn|4 bei installation (und dementsprechender registry und .ini settings auch beim storage directory auf den korrekten ablageort der karte im ram verweist) und wenn du das kannst (du stellst bisher nur nicht überzeugende behauptungen auf), dann erhöhe ich den pnpunloaddelay wert...

--
highend

Hauptsache alle bleiben locker und niemand wird persönlich.

Aber was ich anmerken möchte:

Zitat

Original von highend
das kann navigon doch selber nicht, oder hast du jemals eine erklärung dafür von offizieller seite gesehen, warum das routingverhalten der 2002 durchschnittlich besser ist als das der 2003 version? ich nicht.

Was mich wesentlich mehr und brennender interessieren würde, ist eine Antwort auf die Frage, was an der 2002er-Version denn überhaupt anders (schlechter?) für den Einsatz mit WM2003 sein soll, das Navigon dazu veranlasst hat, überhaupt 2 separate Versionen zu veröffentlichen. Denn dass sie in irgendeiner beliebigen Form nicht optimal mit WM2003 laufen würde, hab ich hier noch nie gelesen.

Zitat

Original von tpmjg
Es werden Fehler moniert und als unbehebbarer Mangel dargestellt, obwohl es vielleicht doch eine - hier schon beschriebene - Lösung gibt.

Hallo tpmjg, vielleicht liest Du ja noch mit - würde mich freuen!

Du bemängelst die fehlende "Experimentierfreude". Ich möchte zu bedenken geben:

1. Wer weiß von diesem Workaround "da draußen"?
2. Dem Otto-Normal-User ist nicht zuzumuten, einen Reg-Editor zu installieren und den entsprechenden Schlüssel zu ändern.
3. Zumal sich Navigon zu diesem Workaround überhaupt nicht geäußert hat.

Punkt 3 ist für mich der eigentliche "Knackpunkt". Es wäre ja leicht, ein kleines Programm zu schreiben (wie es das offensichtlich von Medion gibt), das diesen Wert in der Registry ändert. Und das dann auf der HP bereitzustellen.

Noch viel leichter wäre es (vom N. User), diesen Workaround mit knappen Worten hier als sinn- und wirkungsvoll zu "autorisieren". Aber noch nicht einmal das geschieht. Und das könnte eben auch viele Leute davon abhalten, an diesem Wert zu drehen.

Statt dessen gibt man sich bei N. aber auch nicht die allergeringste Mühe, diese kleinen Hilfestellungen offiziell zu kommunizieren (selbst der Support war ahnungslos).

Nochmals zu Deinem Angebot - Vielen Dank für Deine Bereitschaft, mich bei der Konfiguration meines PPC zu unterstützen. Vielleicht komme ich da noch mal auf Dich zu.
Aber ich möchte zu bedenken geben, ohne undankbar sein zu wollen:

Was ist, wenn ich morgen ein neues Programm installieren oder vielleicht ein altes deinstallieren will? Was ist, wenn ich nach Hardreset ein Backup einspiele? (Ich kann nachvollziehbar _belegen_, daß selbst Sprite den Originalzustand des PPC _nicht_ wiederherstellt.)
Was ist, wenn ich mir eine andere - größere - Speicherkarte gönne? Geht dann der ganze Zirkus wieder von vorne los? - Nein, ich bin nicht bereit, ein Programm als "befriedigend" einzuschätzen, das einen Alleinherrschaftsanspruch auf meinen PPC erhebt...

expalm

Zitat

Original von Tower
Und genau das macht leider auch das Helfen (und Geschwindigkeitsprofilfinden) so unglaublich schwierig.

...was mir besonders ärgerlich vorkommt vor dem Hintergrund, daß wir hier das rad neu erfinden, während die "Macher" sich aus irgendwelchen strategischen Gründen bedeckt halten und noch nicht einmal die allerkleinsten Hinweise geben.

expalm

Zitat

Original von tpmjg
...Beweise mir doch erst mal das Gegenteil, dass MN4 beim Wiedereinschalten nicht nicht irgendwelche Zugriffe auf die Speicherkarte macht - auch wenn eine Karte im RAM benutzt wird, bevor Du es so pauschal als unmöglich abtust...

Guten Abend zusammen,

@tmpjp:
Was Du da abläßt ist doch wirklich gequirlte Sch... (Sorry an alle, aber das musste jetzt raus!)

Erklär mir mal, wieso ein einigermaßen fähiger Programmierer (und ich gehe mal davon aus, dass bei Navigon keine absoluten "Pfeifen" sitzen) unmotiviert auf eine (eventuell nicht vorhandene Speicherkarte) zugreifen soll ? ? ?

Das ist nicht logisch, oder ? Man kann das sicher auch noch verifizieren - einfach den Zugriffspfad auf die Karten (ich glaube das war in der navlib.ini) dediziert auf den Pfad im Hauptspeicher setzen, dann gibt es für MN|4 und alle Derivate keinen Grund mehr auf irgendwelche Speicherkarten beim Start zuzugreifen.

Und als Programmierer bin ich "verpflichtet", die verfügbaren Resourcen vorher abzufragen und nicht blindlings "auf Verdacht" einen (zeitintensiven) Zugriffsversuch zu wagen. Wenn es doch so sein sollte, dann "Gute Nacht"!
Wenn einer meiner Mitarbeiter mir so eine Software zur Freigabe vorlegen sollte, dann könnte er sich auf etwas "Nacharbeit" einstellen...

Aber auch das läßt sich leicht überprüfen, einfach mal - wie von highend beschrieben - eine kleine Karte in den Hauptspeicher kopieren und alle Speicherkarten entfernen. Danach Softrest und dann schau'mer mal ...
Ob sich da was am Verhalten des des MN|4.xxxx ändert ????

Also, was soll die verzweifelte Erklärung mit dem Zugriff auf Speicherkarten und dann dem "Timing-Poblem"? Etwas dünn, deine Argumentationsdecke ...

BTW: Ich fahre immer noch (nur) mit MN4.01 , ich habe keine größeren Probleme (leichtes Nachhinken der 2D-Karte, 3D benötige ich persönlich nicht) mit der Navigation (TOI,TOI,TOI), aber ich will es aufgrund der Berichte hier lieber erst gar nicht mit dem Patch auf 4.2 versuchen ("Ich bin doch nicht blöd...")

Und ja: ich habe die diversen "Lösungen" bzw. Patches im Einsatz - daher (oder eben deshalb?) läuft bei mir der MN|4.01 mit dem POI-Warner relativ annehmbar.
Und das Ganze läuft auch noch auf meiner Lexar 256MB-SD-Karte !!! - der MN|4.01, der POI-Warner, die Karten (Süddeutschland) ...

Zitat

Original von jsacer
(Sorry an alle, aber das musste jetzt raus!)

Nö, Persönliches muss eigentlich nie raus. Das verwässert nur die Sache. Ich diskutier lieber (und gern auch kontrovers) über die Sache. Aber nicht persönlich.

Zitat

Original von Tower

Nö, Persönliches muss eigentlich nie raus. Das verwässert nur die Sache. Ich diskutier lieber (und gern auch kontrovers) über die Sache. Aber nicht persönlich.

@Tower
Du hast ja recht (schäm), aber bei manchen Beiträgen - die erfolgreich jegliche Logik verleugnen - muss ich einfach antworten ...

Aber ich gelobe Besserung ...

OFF-Topic: Wer noch Ü-Eier an Navigon schicken will: Bei der Metro kostet das Ü-Ei aktuell (16.10.-.30.10.2004) im 72-er Pack nur 38,5 Cent Brutto ...
Da wird der ganze Spaß doch richtig billig ... :gap

Zitat

Original von jsacer
Du hast ja recht (schäm), aber bei manchen Beiträgen - die erfolgreich jegliche Logik verleugnen - muss ich einfach antworten ...

Mit der Logik ist das halt so eine Sache. Nicht alles, was unlogisch erscheinen mag, muss zwangsläufig auch falsch sein. Ein Kollege von mir hat da ein Prinzip entwickelt. Das, was bei gesetzlichen Auslegungen am wenigsten logisch erscheint, ist am Ende richtig. Seine Trefferquote ist dabei übrigens sehr erstaunlich.

Zitat

Original von jsacer
Du hast ja recht (schäm), aber bei manchen Beiträgen - die erfolgreich jegliche Logik verleugnen - muss ich einfach antworten ...

Wie schön, dass ihr mit eurer Logik - und der Unterstellung, dass nicht sein kann, was nicht logisch erscheint - sicherlich immer ans Ziel kommt... Ich bin seit fast zwei Jahrzehnten in der Software-Entwicklung tätig und habe schon ganz andere Pferde kotzen sehen - und auch erlebt, wie häufig der Fehler nicht im, sondern vorm System sitzt und selbst bei Abhilfeversuchen unbeirrbar so weiter macht.

Bei mir jedenfalls friert MN4 seit der Registry-Änderung nicht mehr ein. Ich unterstelle dagegen nicht, dass es deshalb auch bei jedem anderen so sein muss, aber Versuch macht kluch und kostet hier jeden anderen, der das Problem noch hat, nur wenige Minuten - im Gegensatz zu den nicht endenden Postings, warum es eigentlich nicht so sein sollte.

Die Tatsache, dass Navigon solche Hinweise nicht gibt, muss ja nicht heißen, dass damit das Problem nicht lösbar ist. Auch Medion bzw. deren Zulieferer Yakumo/Mitac haben damals den Registry-Patch erst nach massiven Druck durch Aldi bereitgestellt, weil sich dort viele über das gleiche Problem im Herbst-2003-Bundle beschwerten bzw. das Bundle deswegen zurückgaben.

Wenn es genauso leicht wäre, bei Navigon das Produkt gegen Geldrückgabe umztutauschen, wie bei Aldi oder Aldi inzwischen ein MN4-basiertes Bundle angeboten hätte, würde es sicherlich auch schon anders um die Qualität der Software bestellt sein, aber so ist es leider nicht und deshalb sind wir hier so auf kreative Selbsthilfe angewiesen.