autostart von gmenu2x verhindern


boeseronkel2k

Active Member
Staff member
Joined
Oct 9, 2005
Messages
985
Habe ein problem, habe gmenu2x aufm nand im autostart - aber habe gmenu2x zersägt, d.H. bekomme nur nen schwarzen bildschirm
kann ich den autostart durch irgendne tastenkombination überspringen?

-edit einfach alle gedrückt: geht ^^
 
Oder die Autostart deaktivieren? Öh, ach so, wenn man alles auf dem NAND hat kommt man ja gar nicht ran :lol:
Drum hab ich Gmenu sicherheitshalber auf SD. Es sollte aber auch möglich sein Gmenu2X auf dem NAND, die Autostart aber auf der SD zu haben. Dann kommt man immer "rein" wenn man die SD entfernt :)
 
Es mag zwar Vorteile haben, das Gmenu aufs NAND zu speichern - aber mir fallen im Moment überhaupt keine ein ...

Aber eine Menge Gründe dagegen:
- Flash hat nur eine beschränkte Anzahl an Schreibzyklen, bevor es kaputtgeht; das NAND läßt sich nicht so einfach austauschen wie eine SD; bei Gmenu muß ich aber andauernd irgendwelche Parameter neu konfigurieren (neue Progs kommen hinzu, ich teste die Taktraten, ändere Lautstärken, scanne Karten erneut, verschiebe zwischen Sektionen etc.)
- auf jeder meiner SD-Karten habe ich Gmenu mit einem anderen Skin; so komme ich nicht durcheinander: meine SNES-Karte hat ein blaues Liquido-Gmenu, meine ScummVM-Karte ein rotes Standard-Gmenu, meine Video-Karte hat gar kein Gmenu (stattdessen meldet sich der GP2X mit dem wunderschönen Nightmare-Before-Christmas-Skin - bis auf diesen ist mein NAND leer) etc.
- die Gmenu-Einstellungen auf der SD-Karte kann ich in jedem Kartenlesegerät bearbeiten - den NAND nicht
- wenn Du eine CD oder DVD brennst, und ein hübsches Auswahlmenü für den Inhalt der Scheibe dazupacken willst: speicherst Du das Menü dann mit auf die CD, oder nur lokal auf Deinem Rechner? Begründe Deine Antwort. ;)
- ach ja, und dann war da auch noch das Problem mit dem Autostart - das fällt damit auch weg. Motto: Karte raus = System sauber

Falls jemandem dennoch irgendein Grund einfallen sollte, Gmenu im NAND zu haben: ich lerne immer gerne dazu!

edit:
Da man sich als User kaum einen Überblick darüber verschaffen kann, wann unter welchen Umständen Schreibzugriffe aufs NAND stattfinden, sollte man vielleicht mal einen Erfahrungs-Sammel-thread dazu starten (und oben anpinnen). Zum Beispiel gehe ich jede Wette ein, daß jedesmal ins NAND geschrieben wird, wenn ein Movie mit 2*X drücken beendet wird - denn beim nächsten mal weiß der GP noch, wo er war, und auf die SD hat er's definitiv NICHT geschrieben. Deshalb beende ich Filme lieber per Power-Off als per X. Aber wirklich gute Erfahrungswerte und entsprechende Tipps/Workarounds fehlen halt in dieser Hinsicht noch dringend.
Aber eben auch weil scheinbar häufiger ins NAND geschrieben wird als man optimistisch denkt, ist es umso wichtiger, so viel wie möglich NAND-Speicher LEER zu haben. Damit sich die Schreibzugriffe über möglichst viele leere Sektoren streuen können. Das gilt natürlich auch für SDs. Eine SD, auf die ich oft schreibe, sollte a.) mäglichst viel freien Speicher haben (200 freie MB auf einer 1GB-Karte sind dann nicht zu viel) und b.) möglichst kleine Cluster (wobei man die Größe der Hardware-Cluster auf der SD kennen sollte) und c.) tausche ich nach einiger (längerer!) Zeit die belegten Blöcke aus (auf die belegten 800MB ist nur ein einziges Mal geschrieben worden, auf die freien 200MB dagegen häufiger; also versuche ich, einen Teil der dauerhaften Daten dorthin zu legen, wo ich in Zukunft gerne weniger Schreibzugriffe haben möchte, weil es dort schon viele gab, wobei selten beschriebene Blöcke wieder frei werden).
 
Modran said:
[...]Damit sich die Schreibzugriffe über möglichst viele leere Sektoren streuen können. [...]
Bei FAT werden Schreibzugriffe gestreut? Das wäre mir neu. Ich dachte gerade da das nicht passiert, ist FAT anfällig für Fragmentierung und allgemein ein Flash-unfreundliches Dateisystem.
Modran said:
[...]ich [tausche] nach einiger (längerer!) Zeit die belegten Blöcke aus (auf die belegten 800MB ist nur ein einziges Mal geschrieben worden, auf die freien 200MB dagegen häufiger; also versuche ich, einen Teil der dauerhaften Daten dorthin zu legen, wo ich in Zukunft gerne weniger Schreibzugriffe haben möchte, weil es dort schon viele gab, wobei selten beschriebene Blöcke wieder frei werden).
Wie stellst Du das an?
 
Lox2Eagle said:
Modran said:
[...]Damit sich die Schreibzugriffe über möglichst viele leere Sektoren streuen können. [...]
Bei FAT werden Schreibzugriffe gestreut? Das wäre mir neu.
Nein!
Das Filesystem hat damit nichts zu tun. Ich meine damit eine generelle Eigenschaft von SD-Karten (und anderen Speichern auf Flash-Basis).
In der Theorie läuft es so: zu jedem Speicherblock in der SD-Karte wird zusätzlich ein Wert gespeichert, wie oft in diesen Speicherblock geschrieben wurde. Der Controller INNERHALB der SD-Karte versucht nun, die Schreibzugriffe so zu verteilen, daß zuerst selten geschriebene Blöcke neu geschrieben werden. Laut Wikipedia gibt es hier deutliche Qualitätsunterschiede in den Streuungs-Strategien in der Firmware der vrschiedenen SD-Karten-Hersteller, was ich allerdings bisher selbst noch kaum austesten konnte (für einen aussagefähigen Test müßte man insg. ca. 100 SD-Karten so lange stressen, bis sie kaputt sind. Danke, nicht mein Job.)
Lox2Eagle said:
Ich dachte gerade da das nicht passiert, ist FAT anfällig für Fragmentierung und allgemein ein Flash-unfreundliches Dateisystem.
Das FAT-System kann da nix für, das ist sogar recht fehlerunanfällig. Im Prinzip. In der Praxis kommt es darauf an, wie es verwendet wird. Wie halt immer ... ;)
Nicht umsonst kann jedes heutige System (Mac, Linux, Dig-Kameras, Handys ...) das FAT-System. Nur Windows kann es nicht. Also, es kann schon, aber es will nicht.
- FAT32 unterstützt 265Mio Cluster, Windows (egal welches) nur 4 Mio
- Fat32 kann 8 TeraByte formatieren, außer unter Windows, da sind es nur 2GigaByte ... :twisted:
Lox2Eagle said:
Modran said:
[...]ich [tausche] nach einiger (längerer!) Zeit die belegten Blöcke aus ....
Wie stellst Du das an?
Da wirds tricky - aber das macht auch erst bei 24/7-Benutzung Sinn, also egal :)

edit:
Fragmentierung spielt bei SD-Karten überhaupt keine Rolle. Wirklich, nicht die geringste!
Stell Dir vor, Du bist ein 2-GH-Pentium, der gerade den Sektor 1 von der Festplatte gelesen hat. Du hast gute Karten, wenn Du als nächstes den Sektor 3 lesen willst. Doch für Sektor 2 ist es knapp zu spät, das erste Byte davon ist gerade eben schon am Lesekopf vorbeigezischt. Ganz knapp zu spät. Wenn Du jetzt wirklich als nächstes den Sektor 2 lesen willst, mußt Du so lange warten, bis die Festplatte sich ein ganzes Mal um sich selbst gedreht hat. Das sind Millisekunden - für den Prozessor eine Ewigkeit! Und für den Benutzer auch, wenn die Platte nach jedem gelesenen Sektor erstmal wieder dreitausend Sektoren überspringen muß.
Noch schlimmer wird es, wenn Du als nächstes den Sektor 50.000 lesen willst - nun mußt Du auch noch den Lesekopf bewegen und so lange warten, bis der sich über der richtigen Spur eingependelt hat.
Und nun nimm die SD-Karte. Der ist es völlig Wurscht, ob Du Sektor 1, 2, 3 oder 7 Millionen auslesen willst, denn die muß keinen Lesekopf bewegen, und sie muß nicht warten, bis ein Scheibe sich an die richtige Stelle gedreht hat. Sektor 9 oder Sektor 99999, ganz egal (Ausnahme: gecachtes Lesen).
 
@Modran
Mit der Fragmentierung bezog ich mich ausschließlich auf die Streuung und ungleichmäßige Auslastung des Speichers, (von vorne nach hinten alles vollschreiben,) entschuldige den unklaren Ausdruck meinerseits. Wenn sich allerdings ohnehin der interne Controller darum kümmert, spielt es ja keine übermäßige Rolle. Mich wundert in dem Zusammenhang, daß dosfsck bad sectors finden kann, wenn sich doch der Controller um eben diese kümmert.
 
Back
Top