MMI 3G größere Festplatte einbauen
Bevor das Thema "MMI 3G nachrüsten" zu unübersichtlich wird, mache ich lieber mal ein neues Thema auf ...
So, ich habe gestern mal auf verschiedenen Wegen versucht die Jukebox größer zu machen.
Zuerst habe ich den kompletten Dump von meiner originalen Festplatte auf die 320er gespielt. (byteweise unter Linux mit dd)
Die 320er Festplatte hat dann einwandfrei im 3G funktioniert.
Leider ist die 10GB Partition, in der ich auch die importierten Files (hexedit) gefunden habe, die 2. Partition und es folgen noch die 3., extended, 5. und 6. Partition.
Hier mal ein fdisk-Dump von der originalen Platte / der originalen Partitionstabelle:
Disk /dev/sdc: 40 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 3003 24121566 4d QNX4.x
/dev/sdc2 3004 4380 11052720 4e QNX4.x 2nd part
/dev/sdc3 4381 4486 843412 4f QNX4.x 3rd part
/dev/sdc4 4487 4864 3028252 5 Extended
/dev/sdc5 4487 4813 2618595 bb Boot Wizard Hid
Warning: Partition 5 does not end on cylinder boundary.
/dev/sdc6 4814 4820 48195 bb Boot Wizard Hid
Warning: Partition 6 does not end on cylinder boundary.
/dev/sdc7 4821 4864 345397 bb Boot Wizard Hid
Warning: Partition 7 does not end on cylinder boundary.
Da man die 2. Partition (in diesem Fall /dev/sdc2) nicht vergrössern kann, da direkt im Anschluss weitere Partitionen folgen, habe ich 2-7 gelöscht, die 2. größer gemacht (z.B. 256GB) und dann die übrigen dahinter so angelegt, wie sie von der Größe her waren.
Die originalen Partitionen habe ich vorher einzeln mit dd gedumpt und dann auf die jeweiligen Partitionen zurückgespielt.
Das 3G bootet einwandfrei, leider ist die Jukebox in der Quellenauswahl ausgegraut 🙁
Ok, nächster Versuch war mit "diinit -h /dev/sdc2" ein neues, leeres QNX4-Filesystem auf /dev/sdc2 zu erzeugen.
Mounten konnte ich dieses frische Filesystem einwandfrei mit dem Linux QNX4 (readonly) Treiber - ganz im Gegensatz zu der originalen 2. Partition. Diese hat sich bisher hartnäckig gegen ein Mounten gewehrt.
Leider kein anderes Bild am 3G 🙁 Eine kleinere (nur 20GB) 2. Partition habe ich in beiden Konstellationen auch ausprobiert. (hätte ja sein können, dass 256GB einfach zu viel für das arme, kleine 3G ist 😉
Hat aber leider auch keinen Unterschied gemacht.
Spasseshalber habe ich auch mal ein EXT2 Filesystem drauf gepackt. QNX kann eigentlich auch mit einem Linux EXT2 FS umgehen. Leider auch kein Erfolg.
Im Moment bin ich der Meinung, dass das originale QNX4 Filesystem abgewandelt wurde und wahrscheinlich auch noch eine bestimmte Datei im Filesystem dem 3G sagt, dass es eine gültige, funktionierende Jukebox-Partition/Filesystem zur Verfügung hat.
Ich befürchte daher, dass man sich wirklich die Mühe machen muss das Filesystem genauer zu verstehen, um die nötigen Anpassungen vorzunehmen.
Insbesondere müssten man mal schauen, ob bestimmte Verzeichniss-/File-Einträge für die Jukebox nötig sind.
So viel erst einmal dazu ... vielleicht findet sich hier ja noch jemand, der irgendetwas rausfindet ...
Kai
Beste Antwort im Thema
Achso ... Feedback ist natürlich auch durchaus erwünscht! (positives wie negatives)
Also bitte nach dem Test bitte einmal kurz ein paar Zeilen schreiben, das wäre wirklich super 🙂
176 Antworten
Zitat:
Original geschrieben von kbankett
Montag würde mir hervorragend passen, da ich Montag und Dienstag frei habe.
Ich schicke dir gleich mal eine PN ...Nebenbei, ich bin mir der Analyse des EFS Filesystems fertig und habe jetzt damit angefangen einen Linux-Treiber zu schreiben 🙂
Ein paarmal werden wir noch wach ... dann ist EFS readonly Tag ...
Am Montag hatte ich einen sehr interessanten Abend bei Kai.
Er hat die MMI-Konfiguration so angepasst, dass die Datenbank auch für seeeehr große Medien reichen sollte
(Größenordnung: statt der 4.000 standardmäßigen Titel auf 400.000 Titel).
(NB: ich habe nur noch gestaunt über die Virtuosität mit der Kai die entsprechenden Stellen findet, modifiziert und das
Ganze dann wieder konsistent verpackt.)
Nach zwei Anläufen und etwas Warten und Bangen, dass kein kritischer Zustand auftritt, war es dann geschafft.
Das MMI bootet und kann auch größere AMI/USB-Festplatten lesen.
Die Performance lässt etwas zu wünschen übrig, sprich: das Wechseln in neue Verzeichnisse dauert manchmal
eine Minute oder so. Wir führen das darauf zurück, dass die Datenbank während dessen immer noch im Aufbau ist.
Ich habe eine 1TB Festplatte angehängt, die mehr als 300.000 Titel beinhaltet.
Wenn man annimmt, dass das Indizieren von 4.000 Titeln (SD-Karte) einige Minuten dauert, dann könnten (linear gerechnet)
300.000 Titel locker 6 Stunden brauchen. Das läuft im Hintergrund und stört die Wiedergabe normalerweise nicht.
Es gibt noch einen Effekt, dass manchmal (mitten im Verzeichnis) die Wiedergabe beim Sprung auf den nächsten Titel
stehen bleibt. Das AMI läuft ganz normal weiter, nur das Springen zu einem anderen Titel und das Öffnen anderer Verzeichnisse
(auch auf anderen Medien) ist nicht mehr möglich. Ich werde weitere Versuche mit etwas weniger großen Festplatten
durchführen, um zu klären, ob die Datenbankgröße vielleicht doch übergelaufen ist und sich dadurch ein Hänger einstellt.
Soviel erst einmal als Testbericht eines Anwenders.
Ich habe den Eindruck gewonnen, dass es wirklich nur noch eine Frage von Tagen ist, bis das Filesystem des MMI komplett
transparent ist. Vielleicht folgen dann die ersten AMI-Apps (das wärs doch ;-).
Gruß
Günter
Hallo Günter,
ich muss aber auch wirklich sagen, daß du die Spezifikationen natürlich um Lichtjahre überschreitest 😉
Ehrlich gesagt hatte ich mir schon gedacht, daß das System mit 300k Titeln dann doch ein wenig überfordert sein wird.
Naja, das Limit ist auf jeden Fall nicht mehr der limitierende Faktor...
Ja, ich habe einfach schon zu viel Zeit meines Lebens vor einer Tastatur verbracht. Die Tippgeschwindigkeit kommt dann automatisch, wenn die Finger anfangen mit der Tastatur zu verwachsen 😉
Wenn es manchen hier also so vorkommen sollte, als hätte ich zu viel Zeit um immer Aufsätze zu tippen, dann kann ich sie beruhigen. In einer Zigarrettenlänge ist das Thema jeweils durch.
Man muss sich jetzt mal rantasten, bis zu welcher Fileanzahl das System noch ausreichend performant und ohne die von dir beobachteten Abspielprobleme funktioniert.
(hatten wir ja schon drüber gesprochen)
Vielleicht könnte man die Abspielprobleme mit einer noch größeren Datenbank in den Griff bekommen, um aber ehrlich zu sein, 300k Files ist für die arme kleine 5F Unit schon eine Ansage 🙁
Achja, (sollte bis hierhin überhaupt noch jemand meinem getipsel gefolgt sein) der EFS readonly Treiber ist fertig.
Ich fahre nun noch ein paar finale Tests, dann gibt es einen Link zu einem Patch.
Für den Linux Kernel ist die Qualität bei weitem noch zu schlecht.
Ein paar Dinge haben mich an den Rand der Verzweiflung getrieben. Ich habe zu wenig Quellmaterial um wirklich alle möglichen EFS Filesystem Kombinationen zu testen.
In Summe ist das in meinen Augen also noch etwas für Leute, die sich mit dem 5F auseinander setzen möchten, aber noch nichts für einen Linux Kernel.
Sollte sich hier jemand finden, der mich mit einem reichen Fundus an EFS Testfiles versorgen kann, also jemand, der z.B. eine QNX Lizenz besitzt, so könnte man den Treiber sicherlich kooperativ noch verfeinern und dann finalisieren.
Also, nicht scheu sein, sondern einfach bei mir melden. Die wirkliche "schmutzige" Arbeit bleibt bei mir hängen 😉
Grüße,
Kai
Hier kommt nun der versprochene Linux QNX EFS Treiber.
Download.
Eigentlich sollte er sich auf alle aktuellen Linux-Kernel sauber anwenden lassen.
Schön wäre es nur, wenn mir jemand Feedback geben könnte, wenn er ihn ausprobiert bzw. vielleicht auch ein kleine Dankeschön posten könnte, wenn er mit dessen Hilfe etwas total Cooles realisieren konnte.
(wenn ich auch die Hoffnung auf Anwenderfeedback schon fast aufgegeben habe ... leider ...)
Zitat:
Original geschrieben von kbankett
Hier kommt nun der versprochene Linux QNX EFS Treiber.
Download.
Eigentlich sollte er sich auf alle aktuellen Linux-Kernel sauber anwenden lassen.Schön wäre es nur, wenn mir jemand Feedback geben könnte, wenn er ihn ausprobiert bzw. vielleicht auch ein kleine Dankeschön posten könnte, wenn er mit dessen Hilfe etwas total Cooles realisieren konnte.
(wenn ich auch die Hoffnung auf Anwenderfeedback schon fast aufgegeben habe ... leider ...)
ich kann dir wie gesagt hier nicht helfen, dafür bin ich zu doof! Aber ich kann dir "seelischen Motivationsbeistand" leisten! Ich finde es so genial wie du das alles bearbeitest und die auftretenden Probleme löst!! Dafür hast meine Hochachtung! Wenn es nicht solche Spezialisten wie dich gäbe, würden wir noch in der Höhle am kalten Fisch lutschen!
Ähnliche Themen
Zitat:
Original geschrieben von combatmiles
Wenn es nicht solche Spezialisten wie dich gäbe, würden wir noch in der Höhle am kalten Fisch lutschen!
Das wohl eher nicht 😁
Kennst du den Witz mit den 3 Wissenschaftlern, die mit einer Dose Ravioli in einen Raum gesperrt werden?
1. Ingenieur
Hat sich schnell mit vorhandenen Mitteln ein Werkzeug gebaut und den Inhalt der Dose verputzt.
2. Physiker
Braucht schon länger, hat dann aber den richtigen Winkel und die richtige Fallhöhe errechnet und ist so auch an das Essen gekommen.
3. Mathematiker
Sitzt nach Stunden immer noch vor der verschlossenen Dose und murmelt "Nehmen wir einmal an die Dose wäre offen ..."
Ok, passt nicht 100% auf Informatiker ... aber irgendwie schon ein wenig 😉
Zitat:
Original geschrieben von kbankett
Hier kommt nun der versprochene Linux QNX EFS Treiber.
Download.
Eigentlich sollte er sich auf alle aktuellen Linux-Kernel sauber anwenden lassen.Schön wäre es nur, wenn mir jemand Feedback geben könnte, wenn er ihn ausprobiert bzw. vielleicht auch ein kleine Dankeschön posten könnte, wenn er mit dessen Hilfe etwas total Cooles realisieren konnte.
(wenn ich auch die Hoffnung auf Anwenderfeedback schon fast aufgegeben habe ... leider ...)
Ich gebe Dir mal Feedback zum Patchen des Kernels. Scheint alles bis auf eine Datei geklappt zu haben. Ich nutze den aktuellen 3.2.9er Kernel.
sunset linux-3.2.9-gentoo # patch -p1 < efs-patch-v2
patching file fs/Kconfig
patching file fs/Makefile
Hunk #1 succeeded at 101 (offset -1 lines).
patching file fs/qnx-efs/dir.c
patching file fs/qnx-efs/file.c
patching file fs/qnx-efs/i_idx
patching file fs/qnx-efs/inode.c
patching file fs/qnx-efs/Kconfig
patching file fs/qnx-efs/Makefile
patching file fs/qnx-efs/namei.c
patching file fs/qnx-efs/qnx_efs.h
patching file fs/qnx-efs/README
can't find file to patch at input line 1135
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nurp vfs.git-unpatched/.git/config efs/.git/config
|--- vfs.git-unpatched/.git/config 2012-02-17 04:02:10.936057449 +0000
|+++ efs/.git/config 2012-03-01 23:10:36.181711438 +0000
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
patching file include/linux/magic.h
patching file include/linux/qnx_efs_fs.h
Hey - freut mich, daß es wirklich mal jemand ausprobiert! 🙂
Du kannst den Fehler ignorieren. Ich habe den Patch gerade angepasst und neu hochgeladen.
Da hat sich eine Datei aus meinem git Tree eingeschlichen, die ich übersehen hatte.
Wie gesagt, sollte aber auch so schon einwandfrei funktioniert haben.
Interessanter ist, ob es denn auch sauber compiliert. Entwickelt habe ich unter einem aktuellen Entwickler-Kernel. Es sollten aber keine kritischen Abhängigkeiten mehr enthalten sein.
Achso, das i_idx File kannst du wieder löschen. Ist ein Müllfile. Da muss ich mal aus versehen eine Datei unter einem falschen Namen abgespreichert haben. (habe ich auch aus dem Patch entfernt)
Tnx!
Kein Problem, wollte Dich nicht alleine da stehen lassen. :-) Kompiliert hat er ohne Probleme. An der Stelle nochmal Riesenrespekt an Deine Leistung!
Ich habe gerade eben noch die freie Speicherplatzberechnung eingebaut. (vorher hat der Treiber immer 0 Bytes frei gemeldet)
"df -k" liefert da jetzt also den realen Belegungsstand.
Hier liegt der v3 Patch.
@xzpsycco: Hast du auch schon Files gemountet? Vielleicht sogar unter 64bit Linux?
Ich fahre bei mir auf dem Notebook immer noch mit 32bit. Auf einer x64 Plattform habe ich den Treiber noch nicht getestet. (wenn ich da auch keine Überraschungen erwarten würde)
Edit: Die belegten Inodes werde nun auch korrekt angezeigt.
Hi Kai,
habe es nochmal probiert mit dem neuen Patch:
sunset linux # patch -p1 < efs-patch-v3
patching file fs/Kconfig
patching file fs/Makefile
Hunk #1 succeeded at 101 (offset -1 lines).
patching file fs/qnx-efs/dir.c
patching file fs/qnx-efs/file.c
patching file fs/qnx-efs/inode.c
patching file fs/qnx-efs/Kconfig
patching file fs/qnx-efs/Makefile
patching file fs/qnx-efs/namei.c
patching file fs/qnx-efs/qnx_efs.h
patching file fs/qnx-efs/README
patching file include/linux/magic.h
patching file include/linux/qnx_efs_fs.h
Ich könnte Dir bei 64-bit helfen:
sunset linux # uname -a
Linux sunset 3.2.6-gentoo #1 SMP Thu Feb 16 07:53:33 CET 2012 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux
Kannst Du mir evtl. eine Datei geben, die ich mounten könnte?
Gruß
Andreas
Sorry, gerade noch einmal den Patch upgedated. (belegte Inodes)
Nein, die Files kann ich nicht zur Verfügung stellen, da auf diesen Copyright liegt, welches ich auf keinen Fall verletzen möchte.
Du kannst dir aber eine MMI 3G Update CD besorgen. Auf der CD findest du die Files.
Kleiner Zwischenstand zu meinen Tests mir größerer Festplatte (extern USB über AMI):
Nachdem ich eine nicht ganz so riesige Platte konfiguriert habe (ca. 8000 Titel) und
zu testen anfing, wunderte ich mich, dass es schon wieder Verzeichnisse mit "keine
abspielbaren Titel" gibt. Das Thema hat, hat sich allerdings schnell geklärt, nachdem mir
die "freundliche Werkstatt" eröffnete, dass eine neue Software eingespielt wurde
(es sollte geprüft werden, warum der Radioempfang so schlecht ist).
Der Softwarestand ist jetzt: Zug K0206, MU Software 0174
Der schöne Patch für mehr Dateien in der Datenbank ist jetzt natürlich hinüber!
Ein zusätzliche Frage habe ich noch an alle AMI-User:
Die USB-Festplatte startet meistens bei der allerersten Datei - statt da, wo zuletzt ausgeschaltet wurde.
Ich bin mir nicht wirklich sicher, ob das vor dem Update auch so war - ich erinnere mich, dass
zumindest einige Mal an der richtigen Stelle begonnen wurde.
Welche Erfahrungen habt ihr?
Gruß Günter
Zitat:
Ein zusätzliche Frage habe ich noch an alle AMI-User:
Die USB-Festplatte startet meistens bei der allerersten Datei - statt da, wo zuletzt ausgeschaltet wurde.
Ich bin mir nicht wirklich sicher, ob das vor dem Update auch so war - ich erinnere mich, dass
zumindest einige Mal an der richtigen Stelle begonnen wurde.
Welche Erfahrungen habt ihr?Gruß Günter
das hängt meiner Meinung nach eher mit dem Anlaufstrombedarf der Platte zusammen. Es gibt Platten, die brauchen da zu viel.
Meine 1000er Platte im A6 4G spielt immer da weiter wo ich aufgehört habe. Auch nach Tagen...
Ja, die K206 hat dann die Änderungen überspielt 🙁
Doof.
Also wenn du mal wieder hier in der Ecke sein solltest... 😉
Man könnte dann auch mal einen Test mit noch einer größeren DB machen.
So wie es für mich aussieht, sollte die Geschwindigkeit nach dem initialen Scan wirklich besser werden.
Ich habe jedenfalls mal Tests mit einer SD Karte und vielen kleinen Files und vielen Verzeichnissen (insbesondere tieferen Ebenen) gemacht und da auch so ein Verhalten beobachtet.
@combatmiles:
Welche USB-Platte verwendest Du?
Der Anlaufstrom ist sicher meistens grenzwertig.
Meine ist eine WD Passport SE 1TB und hat im alten Fahrzeug mit MMI 2G
ordentlich funktioniert. Selbst wenn (in seltenen Fällen) die Platte nicht
anlief, konnte das durch einen Reset oder Neustart behoben werden und
das System setzte das Abspielen an der alten Stelle fort.
Mit einer 1.8"-Platte wäre man auf der sicheren Seite, die gibt es aber
nicht mit so großer Kapazität.