Fehlermeldung Set ObjectStore...

    Zitat

    Original von KADEWanderer


    Falsch! Der Bedarf für Storage-Memory kommt nicht von der Navigation sondern von Zusatzprogrammen, die installiert wurden oder ihre Daten dort speichern(z.B. VirtcomMgr.exe, Serilot.dll, Captce.exe, ...).


    Da hast du mich IMHO etwas "flasch" verstanden, mal sehen ob ich es genauer ausdrücken kann...


    Die Probleme treten ja, wenn ich das richtig interpretiere, derzeit NUR während der "Laufzeit" der Navigation auf und der "Einzige", der während der Laufzeit der Navigation (inkl. Skin) dann an solchen Dingen durch eine Überwachung/Einstellung ggf Eingreifen sollte, ist der "Skin" selbst, denn nur er hat ja die Probleme...
    Ansonsten kommt es nämlich wieder zu den gleichen Wechselwirkungen, wie wir sie jetzt sehen (RAM Einstellung Shell.xml <-> Skin)


    Ich hoffe das war jetzt etwas besser/verständlicher Ausgedrückt, was ich damit meine... ;)


    Zitat

    Original von KADEWanderer


    Völlig richtig, denn Du kannst NIE wissen, was die Leute wann, wo speichern


    Das nicht, aber durch eine geschickte Überwachung (ich habe da ein zusammenspiel mit "Koord" oder "Koord selbst" im Kopf...) :gap
    Könnte man ggf. den Speicher immer automatisch und dynamisch (ich liebe "dynamisch" :D) ) hochsetzen lassen, wenn ein bestimmter Wert "Freier Speicher" unterschritten wird, BEVOR sich das System das Monsterstück abgreift... (und zurück bei überschreiten eines anderen Wertes...)


    Nur mal so als ersten Gedanken.. :gap

    Zitat

    ...
    Da hast du mich IMHO etwas "flasch" verstanden, mal sehen ob ich es genauer ausdrücken kann...


    Die Probleme treten ja, wenn ich das richtig interpretiere, derzeit NUR während der "Laufzeit" der Navigation auf und der "Einzige", der während der Laufzeit der Navigation (inkl. Skin) dann an solchen Dingen durch eine Überwachung/Einstellung ggf Eingreifen sollte, ist der "Skin" selbst, denn nur er hat ja die Probleme...
    Ansonsten kommt es nämlich wieder zu den gleichen Wechselwirkungen, wie wir sie jetzt sehen (RAM Einstellung Shell.xml <-> Skin)...


    Genau da liegt der Hase im Pfeffer! "DIE PROBLEME" gibt es nicht! Es gibt "nur" die Probleme der "P4x25"-User(GoPal bleibt hängen!) ODER die Probleme der "NICHT-P4x25-User"(Zu wenig Speicher - Buttons+Hintergründe Verschwinden!)
    Die Fehlermeldung zum Thema "ObjectStore = StorageMemory" hat nichts mit der Navigationssoftware zu tun, denn sie benutzt ihn nicht!!! Sie lädt alle Daten in den ProgramMemory! Gern verweise ich nochmal auf diesen Thread Zusammenfassung - der interne Speicher. :gap

    Zitat

    Könnte man ggf. den Speicher immer automatisch und dynamisch (ich liebe "dynamisch" großes Grinsen ) ) hochsetzen lassen, wenn ein bestimmter Wert "Freier Speicher" unterschritten wird, BEVOR sich das System das Monsterstück abgreift... (und zurück bei überschreiten eines anderen Wertes...)


    Toller Gedanke! Nur dann gibst Du Deine gesamte Philosophie auf, nämlich dass ASU nicht im laufenden System aktiv ist!!! :evil:
    Außerdem gab/gibt es das wohl schon bei Navirunner, hieß Speicherscripte/überwachung.(Gab's da nicht auch massive Probleme!?)( 8) :gap
    Aber nichts für ungut, ich diskutiere gerne weiter mit! :) : drink
    Gute Nacht, KADE

    Zitat

    Original von KADEWanderer


    Genau da liegt der Hase im Pfeffer! "DIE PROBLEME" gibt es nicht! Es gibt "nur" die Probleme der "P4x25"-User(GoPal bleibt hängen!) ODER die Probleme der "NICHT-P4x25-User"(Zu wenig Speicher - Buttons+Hintergründe Verschwinden!)


    Gut, und ich rede derzeit nur von letzterem Problem... ;)
    ...Da das 4x25 ein ganz anderes ist... :D


    Zitat

    Original von KADEWanderer
    Die Fehlermeldung zum Thema "ObjectStore = StorageMemory" hat nichts mit der Navigationssoftware zu tun, denn sie benutzt ihn nicht!!! Sie lädt alle Daten in den ProgramMemory! Gern verweise ich nochmal auf diesen Thread Zusammenfassung - der interne Speicher. :gap


    Das habe ich auch nie behauptet oder gemeint...
    ...Menno, hab ich mich wieder zu blöd ausgedrückt... :-D)


    ..ok, noch einen Versuch, mal ganz anders formuliert... :gap


    ...ich meine lediglich, dass wenn ein "Programm" sowieso immer zum "Zeitpunkt" der Probleme am laufen ist, dann sollte sich dieses "Programm" dann auch um die Probleme kümmern, die in SEINER Laufzeit auftreten (können)...
    ...Damit meine ich aber NICHT(!), dass dieses Programm auch für die Probleme "verantwortlich" ist!


    Aber immer wenn es Probleme gibt, dann ist zumindest die Navigation (und somit der Skin) am laufen. Ergo gibt es bereits jemanden, der die Überwachung/Korrektur übernehmen könnte, OHNE sich durch die eingreifenden Handlungen dabei selbst auch noch zusätzlich "ins Bein zu schießen", da es "sich selbst" ja am besten kennt (Besser als jede dritte "Partei"! Besonders auch nach Updates, die die dritte Partei dann auch nicht kennt)...


    Ich fände es daher nur den falschen Weg, wenn sich jetzt auch noch eine "dritte Partei" einmischt, da dass die Sache nur noch weiter verkomplizieren würde, denn diese Dritte Partei kennt ja erst einmal BEIDE nicht, auf die es aber jederzeit "Rücksicht" nehmen müsste, bei seinem "Eingreifen"... ;)


    Vielleicht mal ein Versuch, eines ganz simple ausgedrückten Beispiels... :gap


    Während der "Navigation" will der Benutzer ins Menü, dazu muss er einen Button des Skins anklicken...


    derzeit:
    wird das einfach auch gemacht und weitergeleitet...Folge... ggf. sind die Buttonhintergründe weg.


    neu:
    Benutzer drückt den Button zum Menü, der Skin überpüft nun aber vor der Ausführung/weiterleitung des "Benutzerwunsches" erst einmal die Speicheraufteilung/Speicherzustand und greift ggf. korregierend ein, bevor er diesen "Benutzer-Auftrag" ausführt/weiterleitet...


    Hoffnung.... Buttonhintergründe sind weiterhin da...
    Weil (so die Hoffnung) wer auch immer da ein Problem hat, er dieses Problem nun nicht "vorfindet"...



    Zitat

    Original von KADEWanderer


    Toller Gedanke! Nur dann gibst Du Deine gesamte Philosophie auf, nämlich dass ASU nicht im laufenden System aktiv ist!!! :evil:
    Außerdem gab/gibt es das wohl schon bei Navirunner, hieß Speicherscripte/überwachung.(Gab's da nicht auch massive Probleme!?)( 8) :gap
    Aber nichts für ungut, ich diskutiere gerne weiter mit! :) : drink
    Gute Nacht, KADE



    Neeeee.... Kombiniere Antwort 1, 2 & 4! nicht 'ASU' macht das! (Die 'ASU' Philosophie geb ich icht auf!)
    Grundsätzlich sollte das möglichst eine Partei übernehmen, die immer sowieso am Laufen ist, wenn es Probleme gibt, auch dann, wenn es selbst nicht der Verursacher ist...
    (...und 'ASU' ist das definitiv nicht... ;) )


    (Genau das versuche ich ja die ganze Zeit zu erklären...) :gap 8)



    Also weitere Formulierungen dessen was ich meine, fallen mir jetzt aber nicht mehr ein... :gap


    EDIT:


    Hatte ich völlig überlesen....


    Navirunners Speicherskript machen etwas ganz anderes bisher und auch auf eine ganz andere Weise, als ich es oben beschrieben habe...


    ..Da wird nämlich normal nur per zeitintervall (und das ist IMO das Problem) nur auf noch evtl. im Hintergrund laufende und derzeit nicht benötigte Programme geprüft (Contaktviewer etc.) und diese dann ggf. beendet, nur um "grundsätzlich" Speicher Frei zu machen, mehr nicht!
    Ein "gezieltes" Eingreifen in die Speicheraufteilung, findet da IMHO nicht statt. Insbesondere nicht gezielt funktions-/problembezogen...

    4 Mal editiert, zuletzt von BigBugHmb ()

    Vlt. bin ich ja nicht ganz unschuldig bei den Mißverständnissen, die sich im Nachhinein hier noch ergeben haben. :-D) Ich hätte vlt. in meinen Beiträgen deutlich genug rausstellen müssen, daß das von mir aufgezeigte Problem wirklich nur die aktuellen (und zukünftigen) PNAs mit 64MB RAM betrifft.
    Mir sind zwar noch keine Shots hierzu von PNAs mit 128MB RAM bekannt, aber allein aus der Tatsache heraus, das Brutto das Doppelte an RAM zur Verfügung steht, kann man davon ausgehen, daß diese PNAs immer noch beim PM aus dem Vollem schöpfen können, selbst wenn, übertrieben formuliert, 20MB an freiem StM verpulvert werden.


    Also, die Besitzer der P4x25-PNAs müssen weiter nach der Ursache für die Abstürze suchen und das wird (leider) die große Mehrheit sein.



    Zurück zu den 64MB-PNAs: bei möglichen Lösungsansätzen bin ich der Meinung, daß weder irgendwelche Tools noch GoPal selber vor dem Aufruf irgendwelcher Funktionen kontrollieren, ob auch genug Ressourcen dafür zur Verfügung stehen (eigentlich müßte das in GoPal bereits selber durch die Entwickler berücksichtigt worden sein). Dieser zusätzl. Overhead würde erstens noch einmal Ressourcen benötigen (und was ist, wenn diese schon für den Check nicht mehr ausreichen?) und zweitens das Gesamtsystem in der Performance unnötig belasten.
    Geschickter ist es meiner Meinung nach, schon vor dem Start von GoPal dafür zu sorgen, daß erstens das Verhältnis StM zu PM optimal eingestellt ist (also der StM-Anteil so niedrig wie möglich ist, denn der verändert sich auch nicht mehr während der Laufzeit, sofern nicht grade irgendwas ins RAM protokolliert/gespeichert wird) und zweitens alle zur Laufzeit von GoPal nicht benötigten Ressourcen freigegeben werden (mit Close und nicht mit Kill!).


    Da hier aber schon von viele von GoPal V3 her diese Erfahrung gemacht und das in ihren Skins daher schon realisiert ist (bspw. das Menu/den ContactViewer/das Telefonbuch zu beenden), besteht daher wohl nur in Einzelfällen Optimierungsbedarf.



    EDIT: sch... Smileyersetzung! :-D)

    Zitat

    Original von Ralf25


    Also, die Besitzer der P4x25-PNAs müssen weiter nach der Ursache für die Abstürze suchen und das wird (leider) die große Mehrheit sein.


    Sch....ade! :-D)

    Zitat

    Original von Ralf25
    Vlt. bin ich ja nicht ganz unschuldig bei den Mißverständnissen, die sich im Nachhinein hier noch ergeben haben. :-D) Ich hätte vlt. in meinen Beiträgen deutlich genug rausstellen müssen, daß das von mir aufgezeigte Problem wirklich nur die aktuellen (und zukünftigen) PNAs mit 64MB RAM betrifft


    Ähm, also mir was das schon deutlich genug, weshalb ich ja auch schrieb:


    Gut, und ich rede derzeit nur von letzterem Problem...
    ...Da das 4x25 ein ganz anderes ist...


    ;D

    Das finde ich aber gemein von Ralf uns hier so einfach auszuschließen. Hättest uns je wenigstens einen Moment Hoffnung geben können.... ;D


    Ich habe mir die Beiträge durchgelesen und finde das alle sich ziemlich deutlich ausgedrückt haben und verstehe nicht wieso ihr Euch entweder nicht versteht oder verstehen wollt. :D



    Gruß
    Client

    Zitat

    Original von BigBugHmb
    Ähm, also mir was das schon deutlich genug, weshalb ich ja auch schrieb:...


    Richtig, diese Diskussion hier war auch nicht gemeint. Aber in anderen Freds wurde in 'froher Hoffnung' hier verweisen (4425 repariert - nach der Reparatur ist vor der Reparatur) und KADE hatte dann dort die Erwartungen auch schon dämpfen müssen. Insofern wollte ich nochmal hervorgehoben auf diese Tatsache hinweisen. :)


    Zitat

    Original von client
    Das finde ich aber gemein von Ralf uns hier so einfach auszuschließen. Hättest uns je wenigstens einen Moment Hoffnung geben können.... ;D


    Ja, was soll ich dazu schreiben? Ich find die Situation natürlich auch ärgerlich. Wenn sich in der Grundkonfiguration keine Stabilität einstellt (und es hat ja aktuell den Anschein, wie wenn das Ladeverhalten ausschlaggebend sein könnte), kann ich nur jedem raten, konsequent mit Medion in Kontakt zu bleiben und auf Nachbesserung zu bestehen, solange die 4x25 so instabil laufen.


    Das Medion mit den neuen PNAs wieder zur alten Plattform zurückgekehrt ist, sagt ja auch schon einiges aus. Man kann natürlich nicht hinter die Kulissen schauen, aber der anfänglich geäußerte Verdacht bei Vorstellung der PNAs, das der Wechsel zu Atlas wohl primär aus Kostengründen erfolgt ist, hat sich dann letztlich doch als Schuß nach hinten herausgestellt.


    Das muß nicht stimmen, den Eindruck kann man aber durchaus gewinnen! :-D)


    Hallo BigBugHmb,
    auch mir war das klar. Ich hab nur deshalb nochmal auf die unterschiedlichen Geräte hingewiesen, weil es eine Menge Querleser gibt, die sobald sie etwas von Problemlösung lesen, sofort meinen, es wäre ihres, z.B. hier von Wolle 666, letzter Satz. ;)


    Deine Idee mit der dynamischen Speicherverwaltung hab ich inzwischen auch kapiert.


    @All
    Allerdings muss man hier drei Fälle unterscheiden:


    1. StM-PM: Dazu hat sich Ralf schon geäußert, und ich seh's genauso. - Einmal statisch an eigene Bedürfnisse anpassen.
    2. Verwaltung des PM insgesamt: Dies ist ausschließlich Aufgabe des Betriebssystems. Man kann bestenfalls nicht benötigte Programme manuell schließen(Wie Du selbst beschrieben hast, machen das z.B. die Speicherscripte von Navirunner.). Auch das hat Ralf w.o. beschrieben.
    3. Verwaltung des dem Programm(=Prozess) vom Betriebssystem auf Anforderung zur Verfügung gestellten Speichers(MAXIMAL: 32MB bei CE5.0): Dies ist von "außen" unmöglich, weder per Script noch sonst irgendwie. Dazu müsste das Navigationsprogramm geändert werden.
    Aber das ist gar nicht nötig, da es diese Funktion bereits eingebaut ist.


    Zitat

    Original von Ralf25
    (eigentlich müßte das in GoPal bereits selber durch die Entwickler berücksichtigt worden sein)


    Ja, ist sie. Der Prozess "mnavdce.exe" verwaltet den ihm zugesicherten Speicher(nochmal, 32MB! MAX) dynamisch! Und genau deshalb verschwinden Buttons etc.. Die Hauptaufgabe des Programms ist es zu navigieren, wenn dann noch "Luft ist", kann man auch Bitmaps und POIs anzeigen. Wenn nicht, ist das Ende der Fahnenstange erreicht.
    Die Alternative dazu wäre, die Fehlermeldung:

    Code
    Nicht genug Arbeitsspeicher!
Möchten Sie weiter Navigieren oder ins Menü?":JA,NEIN

    Ich glaube das ist auch nicht in der Sache des Erfinders.


    Bleibt also nur, das Naviprogramm unter CE5.0 nicht zu überfordern und eben gewisse Abstriche zu machen.


    Übrigens: Ich höre schon die Frage, wieso haben dann die 128MB-PNA's DIESE Probleme nicht.
    Gaaanz einfach: Wir haben keine Zeit für "Spielchen". Was nützen uns zusätzliche Features, wenn das Navi hängt! ?( :evil:


    PS.: Habe eben Ralf's Beitrag gelesen

    Zitat

    Richtig, diese Diskussion hier war auch nicht gemeint. Aber in anderen Freds wurde in 'froher Hoffnung' hier verweisen (4425 repariert - nach der Reparatur ist vor der Reparatur) und KADE hatte dann dort die Erwartungen auch schon dämpfen müssen. Insofern wollte ich nochmal hervorgehoben auf diese Tatsache hinweisen.


    Genau das hatte ich oben gemeint.


    Habe mal noch einen kurzen Testbericht zur Speichernutzung drangehängt. Vielleicht bringt er uns weiter.


    Speedy1144
    Bitte schau Dir den Bericht mal an. Was hältst Du von meinen Anmerkungen?
    Und was meinst Du, könnte an meiner Idee hier
    mit dem Zugriff auf "My Flash Disk" was dran sein?


    Gruß,
    KADE

    Hi KADE!


    Zitat

    Original von KADEWanderer
    3. Verwaltung des dem Programm(=Prozess) vom Betriebssystem auf Anforderung zur Verfügung gestellten Speichers(MAXIMAL: 32MB bei CE5.0): Dies ist von "außen" unmöglich, weder per Script noch sonst irgendwie. Dazu müsste das Navigationsprogramm geändert werden.
    Aber das ist gar nicht nötig, da es diese Funktion bereits eingebaut ist.


    Wenn ich Dich richtig verstehe, bist Du der Meinung, daß GoPal zur Laufzeit max. 32MB an PM/RAM/Arbeitsspeicher zur 'freien' Verfügung hat?


    Das kann ich eigentlich aus mehreren Gründen nicht ganz glauben:


    1. das sich ein Programm beim Start am BS anmeldet und sich 32MB auf den Stack legt/reservieren läßt


    2. ich kenne es von Win32-Programmen, daß speziell unter C im Vorfeld bestimmte Bereiche allokiert werden bzw. werden mußte, für Zeichenketten, Arrays, etc., aber schon in C++ geschieht das Meiste dynamisch (man muß u.a. nur für die Garbage Collection sorgen bei 'new'). Man kann natürlich generell Speicher allokieren, aber in den seltensten Fällen macht das Sinn, das OS managt das besser (ist jetzt etwas vereinfacht wiedergegeben).


    3. Gegenfrage: warum sollte der Bedarf auf 32MB limitiert sein, wenn wesentlich mehr an RAM verbaut wurde?


    4. du schreibst:

    Zitat

    Übrigens: Ich höre schon die Frage, wieso haben dann die 128MB-PNA's DIESE Probleme nicht.


    Aber genau das ist doch das Phänomen, grade diese PNAs mit 128MB RAM laufen so instabil (auch wenn es mutmaßlich nix mit dem Speicher zu tun hat).


    5. in Deiner PDF-Liste (habe sie bisher nur grob überflogen) sind zum Start von GoPal 16,2MB belegt (1), in Zeile 8 vor dem PObs-Start 49,8 (= 33,6MB). Das widerspricht doch eigentlich Deiner These, oder habe ich die Liste nicht richtig gelesen?

    Hi Ralf!


    Zunächst danke für Deine Rückmeldung.


    Zitat

    ...
    Wenn ich Dich richtig verstehe, bist Du der Meinung, daß GoPal zur Laufzeit max. 32MB an PM/RAM/Arbeitsspeicher zur 'freien' Verfügung hat?


    Das kann ich eigentlich aus mehreren Gründen nicht ganz glauben:
    ...


    Lies mal hier(original Microsoft)


    Zitat

    3. Gegenfrage: warum sollte der Bedarf auf 32MB limitiert sein, wenn wesentlich mehr an RAM verbaut wurde?


    1. s.o.
    2. Der "riesige" RAM dient dem Multitasking, d.h.:
    - Navi läuft - max 32MB
    - mp3-Player läuft - max 32MB
    - Frau schaut Urlaubsfotos an(PictureViewer) - max 32MB
    - ...


    Zitat

    4. du schreibst:
    Zitat:
    Übrigens: Ich höre schon die Frage, wieso haben dann die 128MB-PNA's DIESE Probleme nicht.


    Aber genau das ist doch das Phänomen, grade diese PNAs mit 128MB RAM laufen so instabil (auch wenn es mutmaßlich nix mit dem Speicher zu tun hat).


    5. in Deiner PDF-Liste (habe sie bisher nur grob überflogen) sind zum Start von GoPal 16,2MB belegt (1), in Zeile 8 vor dem PObs-Start 49,8 (= 33,6MB). Das widerspricht doch eigentlich Deiner These, oder habe ich die Liste nicht richtig gelesen?


    Genau! Lies mal meine Anmerkungen auf der 2. Seite! ;) dann wird bestimmt vieles klarer.


    Gruß, KADE

    Hi KADE!


    Zitat

    Original von KADEWanderer
    Genau! Lies mal meine Anmerkungen auf der 2. Seite! ;) dann wird bestimmt vieles klarer.


    Stimmt, die 2. Seite hatte ich nicht gesehen gehabt.


    Das eine Limitierung des VM auf tatsächlich max. 32MB beim process memory (manchmal wird er auch als object memory bezeichnet) besteht, hatte ich jetzt nicht mehr in Erinnerung. Das eine Grenze besteht, war mir schon bewußt, ich hatte gestern irgendwie ein Vielfaches von 8MB, aber mehr wie 32MB, im Hinterkopf.



    Nun denn, trotzdem bin ich weiterhin der Meinung, daß das nicht das zwangsläufig ein Problem sein kann bzw. muß.
    Der gesamte Bereich ist eingeteilt in 64KB-Blöcken (= pages), die sich Code und Daten teilen. Werden nun vom Programm aus für einzelne Objekte/Daten Speicher angefordert, dann wird zunächst mal auf bisher nicht zugewiesene Bereiche zurückgegriffen und diese werden allokiert.
    Ist der gesamte Adressraum bereits einmal zugewiesen worden und der Task fordert weiterhin zusätzlichen Speicher an, dann kann natürlich auch wieder auf die Blöcke zurückgegriffen werden, die im Vorfeld für andere Objekte/Daten bereits belegt waren, nun aber wieder freigegeben wurde (das sog. page-mapping).


    Das ist jetzt natürlich Aufgabe des Tasks resp. des Programmierers, dafür zu sorgen, das nicht mehr benötigter Speicher zeitnah freigegeben wird und das nicht schlimmstenfalls erst bei Programmende aufgeräumt wird.


    Hier kann es dann aber tatsächlich zu Konflikten und Abstürzen kommen und ich hatte schonmal in einem anderen Posting den Verdacht geäußert gehabt, daß diese durchaus die Folge eines fehlerhaften Mappings (letztlich dann Speichermangel) sein könnten.

    Vielen Dank für die Hilfe hier!!! Bei mir hat es hervorragend geholfen! Bloß gut, dass es Euch gibt!