HDMU 1512 auf Octagon 1008 HD getestet

[Yannick]

Bisher läuft das Image stabil und halbwegs flüssig (leicht träge, aber im Grünen Bereich).
Verwendeter Skin: ValiHDFlex

Einziges Problem bisher: Wenn bereits Picons vorhanden sind und ich andere Picons laden will, schlägt es fehl, da die Meldung kommt, die Picons seien schon vorhanden. Ich musste manuell den Inhalt des Piconordner löschen, um andere Picons laden zu können.

[Yannick]

Inzwischen habe ich HDMU_1542 laufen. Auch hier bis dato keinen nennenswerten Probleme.

Anmerkungen:
- Ich hatte bisher mit allen getesteten HDMU-Images das Problem, dass manchmal die Medung auftaucht "kein Tuner gefunden" oder so ähnlich. Anschließend hat es mir die Bouquets und Senderlisten zerstört. Verdächtige Ursache: Ich glaube mein Octagon mag es nicht, wenn man die CPU etwas höher taktet. So lange ich die Finger vom Overclocking-Menü lasse, scheint der Tuner nicht auszusteigen. Falls es doch noch einmal passiert, ohne dass ich in diesem Menü war, werde ich mal schauen, ob es einen Crashlog gibt.
- Mein zweiter USB-Stick (per USB-Hub), der als Festplatte eingerichtet ist (16 GB, RECORD, sdb1) wurde beim HDMU 1512 nicht mehr gemounted, nachdem ich ihn von ext3 in ext2 formatiert hatte. Es gabe zwar einen nutzbaren Speicherplatz unter media/hdd, aber dieser Speicherplatt hatte nur 1,6 GB frei, was darauf schließen lässt, dass mein 2 GB-Stick, auf dem das HDMU-Image läuft, als HDD angesprochen wurde. Nach etlichen Neustarts gab ich auf und habe HDMU_1542 installiert. Nun wurde der Stick wieder ohne Probleme als Pseudofestplatte erkannt und automatisch korrekt als HDD eingebunden. Hier sei noch erwähnt, dass mein Image-Stick zwei Partitionen hat, von denen die erste als OCTAGON (FAT32, sda1) und die zweite als HDMU (ext2, sda2) gelabelt ist. Ich vermute mal, dass mein altes Image noch Informationen von meinen erfolgreichen Versuchen gepeichert hatte, als ich noch keinen USB-Hub hatte und direkt auf dem Image-Stick aufgenommen habe (= Pfade über die Aufnaheeinstellungen eingegeben, müsste /autofs/sda2/media/movie/ gewesen sein, was ich aber später, als der USB-Hub mit oben genannten Stick angeschlossen war, manuell in /hdd/movie geändert hatte und mit ext3 auch klappte).

Edit: Ok, HDMU_1542 ist schon wieder ein alter Hut. Eben habe ich gesehen, das v1599 verfügbar ist. Das geht ja zu wie im Taubenschlag

[Yannick]

HDMU_1599 hatte ich nur einen Tag installiert und bin dann auf 1622 gewechselt.
Dies läuft nun seit Tagen stabil, lediglich mit Timeshift ist etwas faul. Wenn ich mich recht entsinne, drückte ich die Pausetaste und als ich wieder Pause drückte, war Timeshift verschwunden. Bug oder Feature? Wie auch immer, laut Changelog ist in neueren Images Timeshift gefixt worden und vielleicht wird der Fehler im nächsten Image dann bei mir auch verschwunden sein.

PS: Irgendwo hier im Forum habe ich mal den Tipp gelesen, wie man den verzerrten Bootbildschirm verhindern kann. Ist diese Funktion inzwischen in den Images eingebaut?
Bei mir ist es im Moment so: Wenn ich einen E2-Neustart mache, habe ich am unteren Bildrand häßliche Dreiecke im Bild. Erst wenn der Bootvorgang wieder losgeht, wird das Bootloge normal angezeigt. (Priorität = 0, da nur unbedeutender kosmetischer Fehler)

[Macbest]

Das war ein Eintrag in der rcS.......finde den Beitrag gerade nicht.

[Yannick]

Das Board ist verdammt träge. Die Suchfunktion hat eben geklappt und ich habe den Thread wieder gefunden:
http://www.hdmedia-universe.com/boar...hread.php?2782

Zwischen den Zeilen habe ich entnommen, dass ihr diesen Fix nicht verwendet. Eventuell werde ich mich dann mal ans Werk wagen. Bei externen Images kann ich hoffentlich nichts kapput machen.

Edit: Ich habe es soeben getestet. Die "Pyramiden" am unteren Bildrand beim Runterfahren sind geblieben, aber mir fiel zum esten Mal auf, dass anstelle des Spinners ein transparentes Fenster auftauchte (Zufall oder wegen Scriptanpassung?). Wie auch immer, ich vermute mal, dass redoom ein anderes Problem gemeint hat. Er spricht von Pixelfehler beim normalen Booten wegen des Spinners. Ich habe hingegen beim normalen Bootvorgang keine Störungen. Zumindest sind mir noch keine Pixelfehler aufgefallen.

[Yannick]

HDMU_1667 läuft seit 2 Tagen stabil. Bisher noch nichts Negatives gefunden.
Lediglich beim gestrigen Schneesturm wurde keine Signal mehr empfangen und die Box hat sich, nachdem ich den Sender wechseln wollte, aufgehängt. Reboot per Webinterface ging auch nicht mehr, aber per Telnet konnte ich noch einen Reboot ausführen.

PS: Welchen Reboot-Parameter sollte man verwenden? Ich hab's mit "reboot -f" gemacht.

[santa]

init 6 zum rebooten.

[Yannick]

Lautet der Befehl einfach nur "init 6" oder "reboot init 6" oder wie ist die Antwort zu verstehen?

Edit: Ok, Tante Google sagt:
init 6 oder shutdown -r now ist das Gleiche.

[santa]

In Linux gibt man mit init und eine Zahl den nächsten zustandslevel an.
Bei mips und PCs gibt es 7.
Bei den sh4 wurden nur 3 implementiert, 0 um die Box auszuschalten und 6 für reboot.
Shutdown gibt es bei uns so auch nicht.
Durch runlevel wird das System normal sauberer beendet als durch ein reboot oder halt allein.

[Yannick]

HDMU_10630 läuft soweit, aber das VPS-Plugin führte zu Bootloop.

Siehe http://www.hdmedia-universe.com/board/showthread.php?2967-VPS-Plugin-auf-den-Feed&p=33875&viewfull=1#post33875

Edit: Irgendwie läuft die Navigation flüssiger als sonst. Wurde irgend etwas geändert, wodurch die Performace gesteigert worden sein könnte?