merkwuerden

@syborg dBox-Taste -> Einstellungen -> Aufnahme -> Direktaufnahme Einstellungen -> Bei Sofortaufn. Verzeichnisauswahl -> aus Und beim Aufnahmeverzeichnise das richtige einstellen, das wird dann genommen.

Wird wohl irgendwelcher nicht-standardkonformer Müll in der Tonspur sein. Das hier: http://www.keywelt-board.com/index.php?showtopic=58615&st=23 schafft vermutlich Abhilfe. Paket Avia.zip runterladen, da draus nur die Datei avia_av.o nach /var/modules kopieren, Rechte auf 755. Box neu starten, Ruhe ist mit dem Spuk. Funktioniert ab dem KW-November-Image.

Hm... scheint wohl am ursprünglichen mpeg was nicht so zu sein, wie's ProjectX gerne hätte. Ich hab grade nochmal selber nachgesehen, wenn das mpeg in Ordnung ist, kommt auch ein TS dabei raus. Hat Dein mpeg vielleicht keine Tonspur, sprich ist ein m1v oder m2v? Dann geht's so einfach nicht. ProjectX weigert sich, Dateien ohne Tonspur zu muxen. Geht aber dann auf einem Umweg: - demuxen mit ProjectX - die demuxten Dateien mit TMPGEnc (Plus) und den drin enthaltenen Mpeg-Tools wieder zu mpg muxen - mpg mit ProjectX zu TS So mach ich's jedenfalls bei solchen Fällen.

Mal 'ne neue Info: Alten sectionsd im Januar-Image zu verwenden, geht nicht. Original schon gleich garnicht, weil vor November 2005 ja noch die alten Libs (libstdc++.so.5) verwendet wurden, in der libstdc++.so.6 sind Sachen rausgefallen, die ein alter sectionsd da haben will. Die Lib zusätzlich einzuspielen, geht nicht, das beißt sich dann derart, daß das Image überhaupt nicht mehr durchbootet. Habe den sectionsd von Juli 05 mal mit den neuen Libs compiliert, bringt genauso wenig. Startet zwar, verabschiedet sich aber bei jedem (!) Zappen. Das bringt's also auch nicht. Ich vermute mal, daß da im CVS zuviel anderes Zeug für den aktuellen sectionsd-Murks mit geändert wurde, das paßt wohl mit älteren Versionen nicht mehr zusammen. @Worschter Du hattest mir doch vor einiger Zeit mal den sectionsd v1.193 von Anfang Oktober mit den neuen Libs compiliert, war für's Keywelt-November 2005. Haste den zufällig noch irgendwo rumliegen? Dann könnte ich mir den nochmal ansehen. Ich hab den bei mir leider schon entsorgt. Wenn nicht, geht die Welt auch nicht unter. @kebeaga Hatte Dir ja per PN schon geschrieben, wir machen dann hier offiziell weiter mit der Störungssuche, wenn Du noch willst.

Zeigt Dir (per telnet) oder die Sysinfo im Image. Bsp. Keywelt Januar-V4: mtd1: 00520000 00020000 "root (squashfs)" Die rot markierte Angabe ist die reservierte Partitionsgröße (hexadezimal) von root und darf keinesfalls überschritten werden, sonst ist nach dem Flashen das Image im Arsch. Im Beispiel sind die 00520000 dezimal 5373952 Bytes und ist gleichzeitig die maximale Größe, die das root.img haben darf. Kleiner darf es sein, dann bleibt eben etwas Platz ungenutzt. Wie groß Dein modifiziertes Root-Image wird, siehste erst, wenn Du es mit mksquashfs zusammengepackt hast. Im Januar-V4 sind in root noch 106496 Bytes ungenutzt, da squashfs komprimiert, dürfte real etwas mehr reinzupacken gehen. Mußt Du ausprobieren.

@Openall Laß den avia600 sein, wie er ist. Eine 500er Box interessiert sich überhaupt nicht für den 600er. Im Image gibt es nur einen avia500.ux, und der wird bei einer entsprechenden Box immer verwendet. Dein Problem liegt sicherlich woanders.

Die Karte kannste als Eiskratzer verwenden.

Mit 64 MB RAM wirste vielleicht Windows 2000 alleine grade so zum Laufen kriegen, aber mit Sicherheit kein NFS-SFU dazu. Das System wird permanent mit der Auslagerungsdatei wirtschaften, damit dürfte die Gefahr eines Fehlers/Abbruchs beim Streamen vorprogrammiert sein. Für Windows 2000 und SFU plane mal 256 MB RAM ein. Und mit einem P133 dürfte das auch keine Freude machen.

Zu avi und Direkt Streaming per NFS: generelles Nein Zu mpeg (1 & 2): Geht, aber nicht ohne Umverpacken zu TS (ProjectX kann das). Btw: TS ist kein Video-Format, sondern ein Transport Stream, sozusagen eine Verpackung für's Video samt Zubehör zur Übertragung.

@Worschter Dankeschön , daß Du das erklärt hast. Brauch ich nicht mehr nach der Anleitung suchen, ich finde die nämlich irgendwie nicht mehr. Wahrscheinlich hab ich die wohl versehentlich schon entsorgt...

@Petze Muß ich mal suchen, ob ich die Anleitung noch finde. Auf meiner Festplatte herrscht ein leichtes Chaos, meine ursprüngliche Ordnung ist etwas zum Saustall verkommen. Hab aber auch keine Lust, mal aufzuräumen, da schmeiß ich bestimmt wieder zuviel weg.

Eben. Ich höre jetzt schon das Gefluche von den Leuten, wenn die eine geshrinkte Datei austauschen wollen und hinterher alles hin ist.

Hm... da muß ich mir die Konstruktion im rescue-Plugin mal genau ansehen. Problem könnte werden, daß sed und grep in manch älterem Image nicht vorhanden sind. Schaun mer mal, ob mir da was einfällt. Die Scripterei ist eigentlich nicht so meine Spezialität. Sooo kompliziert ist das nicht. Für den Fall, daß Du MS-SFU am Laufen hast: Vom Bootmanager brauchst Du nur den BootP/TFTP Server und die COM-Schnittstelle für's Log. Dem BootP drehst Du das u-boot aus dem yaddroot auf. Kommt eventuell die Mecker, daß das kein gültiges ppcboot ist, aber kann man ignorieren. Und irgendwo hab ich dieser Tage einen Patch für den BM gefunden, der das Gemaule ein für allemal abstellt. Für yaddroot machst Du eine NFS-Freigabe am PC, Freigabename des Verzeichnisses ist ebenfalls "yaddroot". Encoding ANSI Allow anonymous access, Anonymous UID und GID -2 Permissions: read-write, allow root access Sollte dann funktionieren. Achtung! Zwei NFS-Server am PC vertragen sich nicht! MS-SFU z.B. blockiert den NFS-Server des BM, also bei SFU nicht das Ding vom BM mit starten.

@SnowHead Ich hab übrigens noch die dumme Idee, Dein Script allgemein verwendbar zu machen. Kernels und u-boote sollten sich auch für etwas ältere Images noch auftreiben lassen, irgendwo hatte ich da mal eine Webpage gefunden. Sonst wird das Zeugs eben neu compiliert.

@SnowHead Kernel 1.1.2... was is'n das für Ding? Solltest vielleicht das Script dahingehend abändern, daß da bei der kernel-Variablen korrekt 2.4.31 reinkommt und den Rest dahingehend passend machen. Kriegst gleich 'ne PM mit Link zu einem Kernel 2.4.31 fürs KW-Image. Kannste dann in das Script mit reinpacken. Und: mit dem Kernel 2.4.32 wird das KW-YADD nicht bootfähig sein. Die Kernel-Versionen vom Flash-Image und kernel-yadd müssen übereinstimmen. Das u-boot sollte dagegen unkritisch sein, das KW-YADD wird auch mit dem 1.1.4 booten.

Es wird immer eine neue Datei angelegt, das Original wird nicht angetastet.

Da Du keine Angaben zu Deinem System machst und meine Glaskugel zur Reparatur ist: Gehe nach www.microsoft.com (englische Seite!) und gebe oben in der Suche exakt den Begriff "Installation of performance counters for NFS Server failed" ohne die "Gänsefüßle" ein, Du bekommst 181 Links als Suchergebnis angezeigt, da ist sicher eine Lösung mit dabei. Sonst hilft vielleicht auch Google weiter. Mir sagt der Fehler erst mal nix.

Allegro kannste in die Tonne klopfen, zumindest die freie Version. Hab's selber ausprobiert, ist Krampf hoch zehn. Und kommt von der Performance nie annähernd in die Nähe von MS-SFU. Gibt wohl ein neueres Allegro, das ist aber Löhnware. Und da MS SFU nix kostet, interessiert mich Löhnware nicht.

Einen sectionsd vom 30.07.2005 (der letzte ohne Prem. Sportportal-Patch, das Zeug kam am 15.08. ins CVS) hab ich noch da. @kebeaga PM an mich mit Deiner Mail-Adresse, dann schick ich Dir den zu.

Ich würde die Shrinkerei bleiben lassen, wirkliche Vorteile bringt's wohl nicht.

Biste Dir da sicher? Ich dächte, ich hätte vor paar Wochen per Opera in den Bouquets gebastelt, ging auch.

Geht ganz einfach (und normalerweise auch mit jedem anderen Image): Voraussetzung ist ein gemountetes Verzeichnis zum PC mit Lese- und Schreibzugriff. Sonst wird unter Umständen für die Prozedur der Speicher knapp. Und zum Entpacken unter Windows braucht man das sowieso, siehe weiter oben im Thread. Ich mache das per NFS-Mount. Allgemein: Als erstes schaun wir auf der Box nach, wie die Partitionsaufteilung ist, speziell root und var sind interessant, alles andere ist unwichtig. Per telnet: Oder auch über das Sysinfo-Plugin. Man erhält Auskunft in der Form: root ist hier (Beispiel Keywelt-Januar V4) mtd1, var ist mtd2, brauchen wir gleich wieder. Weiter geht's per telnet auf der Box. Die Partitionen für root und var müssen auf der Box nochmal gemountet werden, im Verzeichnis /tmp/root bzw. /tmp/var. Anschließend wird der Inhalt dieser Verzeichnisse getart, und zwar auf einen freigegebenen und gemounteten Ordner am PC, siehe oben, ich gehe mal am Beispiel vom KW-Image nach /mnt/custom: Die Verzeichnisse /tmp/root und /tmp/var kann man dann wieder löschen, muß aber nicht. Sind halt jetzt wieder leer und eigentlich unnötig. Nach dem nächsten Booten sind se eh weg, also is wurscht. Das Packen geht übrigens recht fix, wieder entpacken dauert dagegegen "etwas" länger. Dann müssen die tarballs auf dem PC wieder entpackt werden, wegen der Symlinks auch über die Box/Freigabe (telnet): Das Zeug liegt jetzt soweit fertig am PC. Weiter geht's auf dem PC: Als erstes wieder die Prozedur mit der Besitzer- und Rechteübernahme, damit sich die Dateien bearbeiten/kopieren/verschieben lassen. Nun in den auf dem PC entpackten Dateien in /root/etc die Datei fstab editieren (mit unix-fähigem Editor, ich nehme Proton32 dazu). Es darf keinesfalls ein Eintrag wie drinstehen, sonst geht beim Versuch, das Zeug über Netzwerk zu booten, das Image auf der Box zum Teufel. Die Box würde aus ihrem eigenen Flash mounten wollen, der kerner-yadd findet dann das Zeugs nicht, fängt gutmütig Reparaturversuche an und repariert dabei das Image im Flash kaputt. Folge: die Box startet nicht mehr -> neu flashen. In die fstab gehört nur das rein, mehr braucht's nicht: Dann noch nachsehen, ob eine rcS.local existiert, beim Keywelt in /var/etc/init.d/rcS.local Bei anderen Images (reinen jffs2 z.B.) eventuell auch in /root/etc/init.d/rcS.local Da drin unbedingt mindestens das auskommentieren oder löschen, falls es vorhanden ist, sonst meckert der kernel-yadd: Normal kann auch raus, ist im kernel-yadd fest eincompiliert. In den normalen YADDs gibt's eine rcS.local überhaupt nicht. Zum Abschluß noch den Inhalt von /var nach /root/var verschieben, in /root den Kernel löschen (vmlinuz, wird nicht gebraucht) und das Ganze dann ins Verzeichnis /yaddroot rein. Für /tftpboot einen kernel-yadd aus einem originalen YADD nehmen (muß zur Kernel-Version des Images passen!) und das passende u-boot dazu aus dem YADD (bzw. meines von oben, falls die aus dem YADD nicht gehen wollen). Das Image ist damit fertig zum Booten über Netzwerk. Auch hier gilt (zumindest für Neutrino, Enigma hab ich da noch nicht geschaut): keinesfalls auf der Box die Netzwerkeinstellungen ändern und dann über "jetzt zuweisen" laden, damit hängt sich das Image weg. Aber da das Image ja eh auf der Box war und damit vermutlich auch fertig eingerichtet ist, braucht man da normal sowieso nicht ranzulangen. Das so zum YADD gewordene Flash-Image sollte genau so funktionieren, als wenn es über den Flash der Box gebootet wurde. Hab die Prozedur grade nochmal anhand des Keywelt-Januar-V4 im Hintergrund mitgemacht, funktioniert einwandfrei. Liest da der "Feind" etwa hier mit? Ging jedenfalls 'ne ganze Zeit lang nicht, ich hab's mit diversen YADDs aus dem Zeitraum Oktober 2005 bis Mitte Januar 2006 versucht, no chance. Nö, geht nicht, weil das Image dann keine Partitionseinteilung wüßte. Die Box würde damit nicht booten. Außerdem ist in einem Standard-YADD Neutrino, Enigma und Lcars gleichzeitig drin, das würde nie und nimmer in die 8 MB Flash passen. Was geht: ein nach der oben genannten mount/tar-Methode ausgelesenes Flash-Image am PC zu modifizieren und anschließend die Partitionen wieder neu zu verpacken und partitionsweise zu flashen. Dazu braucht's aber Linux auf dem PC (mit Cygwin unter Windows wirds Scheiße). Und die Prozedur ist nicht ganz einfach, weil die Partitionsgrößen festgelegt sind und keinesfalls überschritten werden dürfen. Ich hab das bisher nur einmal mit einer squashfs-Partition gemacht. Hat aber funktioniert. JFFS2 müßte auch gehen, hab ich mich aber noch nicht damit befaßt. Fragt aber bitte jetzt keiner, wie das genau geht, ist schon 'ne Weile her. Und die Anleitung dazu müßte ich erst mal wieder suchen.

Jaja, die scheiß Rechteverwaltung in XP Home... mich tät mal interessieren, was diese Idioten bei MS veranlaßt hat, die Sache derart zu kastrieren. Schau mal hier nach: http://www.fajo.de/portal/index.php FaJo XP File Security Extension (XP FSE) ist das, was Du brauchst. Damit kriegst Du die Rechteverwaltung, wie sie auch unter Win2k/XP Pro vorhanden ist.

Die Geschichte ist etwas kniffliger, als man meint. Und irgendwo vernünftig (deppensicher) beschrieben ist schon gar nichts... Entpackst Du das Yadd-Archiv (tar.bz2) unter Windows mit den Tools zum Entpacken, die dietmarw auch mit anbietet? Dann wird's Scheiße, weil die Symlinks alle kaputt sind. Zum Entpacken wird eine emulierte Linux-Umgebung unter Cygwin verwendet, das schreibt die Symlinks so, daß sie für Cygwin funktionieren würden. Damit kommt aber kein richtiges Linux mehr klar. Wie auch, die Suppe, die Cygwin da kocht, schmeckt hinten und vorne nicht. Cygwin ist allgemein Scheiße für's Arbeiten an dbox-Images. Du mußt das Archiv, speziell den Tarball da drin, unter einem echten Linux-System entpacken, damit die Symlinks richtig geschrieben werden. Das geht auch über die dBox über einen NFS-Mount (CIFS müßte auch gehen, hab ich aber nicht probiert, weil ich generell nur noch mit NFS arbeite (Microsoft SFU). Ich gehe im Folgenden von SFU unter Windows 2000 Professional aus, Vorgehen unter XP Pro analog, mit XP Home kann's Abweichungen geben, da kenne ich mich aber nicht aus... Entpacke zuerst das bz2, das geht mit den Tools von dietmarw: Den Tarball steckst Du dann in ein NFS-freigegebenes Verzeichnis, das mit der dBox gemounted ist, und auf daß Du Schreib-/Lesezugriff hast. Ich nehme mal als Beispiel den Mount /mnt/custom. Auf die dBox gehts Du per telnet: Die Aktion dauert etwas (durchaus 4-5 Minuten), die Box ist ja nicht die Schnellste. Du bekommst dann auf dem PC im freigegebenen Verzeichnis die beiden Unterordner "tftpboot" und "yaddroot". Da ist alles drin mit korrekt funktionierenden Symlinks. Wichtig! An der Stelle mußt Du den Besitz der erzeugten Verzeichnisse samt Inhalt unter Windows ändern, sonst kannst Du die u.U. nicht korrekt kopieren, Löschen geht auch nicht! (Fällt eventuell bei CIFS-Mount weg, hab ich nicht probiert.) Beiden Verzeichnisse markieren -> Rechtsklick -> Eigenschaften -> Sicherheitseinstellungen. Du bekommst als erstes eine Warnmeldung, daß Du die Berechtigungen nur anzeigen kannst. Bestätigen, die Felder für die Berechtigungen sind alle ausgegraut. Gehe auf Erweitert -> Besitzer. Den neuen Besitzer auswählen und Haken rein bei "Besitzer für Untercontainer und Objekte ersetzen". Übernehmen und OK, Eigenschaften-Fenster schließen. Nochmal Eigenschaften der Verzeichnisse aufrufen, sonst hast Du auch als Administrator nur Ausführungs-/Leserechte, keine Schreibrechte. Entsprechenden Benutzer markieren (ich nehme der Einfachheit halber "jeder", Haken bei "Vollzugriff" rein, übernehmen, fertig. Jetzt kannst Du mit dem Zeug anstellen, was Du lustig bist. Nur noch das u-boot austauschen, und das Yadd wird korrekt booten. Kannst das entpackte Zeugs dann auch mit Zip oder Rar platzsparend archivieren, wenn Du willst, die Symlinks bleiben dabei erhalten, sind eigentlich nix anderes, als Textfiles in einem kombinierten ANSI-/Unicode-Format mit dem Attribut "System". Aber versuche nicht, die Symlinks mit einem Editor zu ändern, das geht nach hinten los. Mit einem Hex-Editor geht's aber... Und gleich noch ein Hinweis, falls Du mal ein normales Flash-Image zum Yadd umwandeln willst. Sowas kann man auch machen, ich hab z.B. das Keywelt-Januar-V4 als komplett vom Netzwerk aus bootfähige Version: In der /etc/fstab darf nichts weiter drinstehen, als maximal das: Keinesfalls Einträge wie sonst geht beim Booten des Yadds das Image auf der Box zum Teufel. Es dürfen beim Booten über Netzwerk auch keine Module für CIFS- oder NFS-Unterstützung geladen werden (normal in der rcS.local), bringt das Yadd in Verlegenheit, da die Sachen im kernel-yadd fest eincompiliert sind. Wenn da irgendwie das drinsteht, auskommentieren! Der Kernel aus dem eigentlichen Flash-Image läßt sich nicht verwenden, geht nur mit einem fertigen kernel-yadd aus einem Yadd, das zur Kernelversion des Images paßt. Und versuche niemals, bei einem gebooteten Yadd auf der Box unter Neutrino die Netzwerkeinstellungen zu ändern und per "jetzt zuweisen" sofort zu aktivieren. Dabei stürzt das Zeugs ab, Du kannst dann gleich die Box neu booten. Die geänderten Netzwerkeinstellungen werden beim Runterfahren der Box in Deep-Standby automatisch abgespeichert (auf'm PC im yaddroot). Viel Spaß beim Experimentieren!

@petze Gleich kommt hier ein Anhang mit u-boot v1.1.2 und 1.1.4, muß nach /tftpboot und dem Bootmanager als Startfile beigebracht werden. Ich hab beide Dateien getestet, damit lassen sich YADDs problemlos über Netzwerk auf die Box laden. u_boot_yadd_dbox2.zip