BPanther's Neutrino Forum

Ggf. mal in der Datei /etc/profile in der letzten Zeile DEBUG=1 setzen, dann kommen seriell mehr Meldungen vom laden der Module, also ob OK und im Fall der audio*.elf auch welche genau geladen wird.

Ok, das teste ich mal und gebe ich bescheid

debug=1 hat nicht geholfen

sonst noch eine idee?

edit: machte mir sogar ein gröberes problem. die kathi bleibt beim lade module einfach stecken und fährt nicht mehr hoch.
ich habe jetzt debug=0 wieder gesetzt, aber ändern tut sich da im moment nichts. hochfahren nur noch ohne platte.

eine idee?

update2: beim lade module ist bereits eine ftp-verbindung gegeben, so konnte ich audio.elf löschen und die kathi bootet wieder.

Alternativ mal ein Image auf USB installieren > da gibt es keine Platzprobleme mit der Audiofirm.

dummi hat geschrieben:debug=1 hat nicht geholfen

Es hätten doch Meldungen kommen müssen, und das sogar in Farbe und bunt. Du hast auch wirklich nur das vorhandene DEBUG=0 in ein DEBUG=1 geändert? Es mußte also nur die 0 in eine 1 geändert werden. Wenn Du hingegen wirklich ein debug=1 hinzugefügt hast, dann wird das nichts, denn das hast Du klein geschrieben, es muß aber komplett groß geschrieben werden. Linux nimmt das sehr genau mit der Schreibweise, z.B. TesT ist nicht tEst oder TEST - das gilt übrigens auch für Dateinamen.

dummi hat geschrieben:update2: beim lade module ist bereits eine ftp-verbindung gegeben, so konnte ich audio.elf löschen und die kathi bootet wieder.

Jupp, eben genau deswegen besteht bereits dort Telnet und FTP - sofern man vorher natürlich die korrekten Netzwerkdaten eingegeben hatte. So kann man problemlos Fehler beheben ohne gleich extra nen serielles Kabel zu bemühen oder gar neu flashen zu müssen.

Ich habe die 0 einfach auf 1 überschrieben und die datei eingespielt. Es ist auch dort dann mit 1 vorhanden.
Bis auf audio.elf und timeshift funzt jetzt soweit alles.
Timeshift über usb wundert mich schon ein wenig, denn mein kabelreceiver macht gleichzeitig 2 hd aufnahmen und ermöglich noch über den einzig vorhanden usb anschluß noch ein in hd aufhenommene sendung zu gucken. Also ein usb anschluß mit drei hd quellen.

Hauptsache die Datei hat dann die identische Größe von 470 Bytes gehabt, denn es gibt ja leider einige FTP-Programme, die die Dateien dann beim hochladen verstümmeln (sofern man den richtigen Editor benutzt hat), diese also danach defekt sind.

Du kannst die UFS910 nicht einfach mit anderen Receivern vergleichen, dafür ist sie halt zu schlecht schon vom RAM her in der normalen Standardausstattung. Nicht umsonst haben ich und andere inzwischen 128MB RAM dort eingebaut (erspart dann den langsamen Swap), die 64MB waren halt schon immer zu knapp bemessen. Der interne SATA war so gesehen eh "Pflicht" für eine bessere und stabilere Übertragung. So mache ich Dir auch mit der UFS913 (hier leider nur USB möglich) locker vor, daß ich 4 HD-Aufnahmen laufen lasse und noch ein 5. HD-Programm schaue. Hat aber garnichts zu sagen, denn die UFS913 ist da weitaus leistungsfähiger schon von der CPU aus.

Telnet Beispiel, Speed-Test HDD (nur lesend, interner SATA): Das ist zwar nur lesend, zeigt aber was theoretisch lesend möglich wäre. Das geht aber sofort runter, wenn man aufnimmt, gerade bei HD, schließlich ist das nur ein mechanisches Laufwerk - und das wird gerne vergessen.

Bei EINER HD-Aufnahme mit einer Bitrate von "nur" ~10000: Eine ZWEITE HD-Aufnahme mit einer Bitrate von "nur" ~9100: Wie man sieht, gehts rapide bergab, was ja auch logisch ist - wohlgemerkt: Das ist nur der Speedtest für's LESEN während der Aufnahmen.

Und da ich frech bin, noch eine 3. HD-Aufnahme mit einer Bitrate von "nur" ~9200: Dann noch nen HD abspielen zu wollen, grenzt an eine Unmöglichkeit. Man sollte auch einfach mal daran denken, daß es eben mechanische Datenträger sind, welche nunmal Grenzen haben. Mach den Test einfach mal bei Dir selbst mit der UFS910...

Achja, den RAM-Verbrauch noch vergessen bei den 3 Aufnahmen: Hat man da also bei der UFS910 nur die 64MB und ist somit auf den Swap angewiesen, muß auch der Stick sehr schnell sein, ansonsten ist der die Hauptbremse weil er nicht mehr so schnell auslagern kann...

Wow, danke für die zusammenstellung, wirklich aufschlussreich!
Ich habe den swap auf die platte als dritte partition mit 128 mb angelegt. Macht bei der timeshift aber keinen unterschied, ob hdd oder ssd an der kathi hängt. Ich merke keinen unterschied. Stick habe ich gleich vom anfang an als nicht schnell genug abgelehnt und lieber die platte eingerichtet.

Axo, datei ist dann wohl vermurxt. Hat nur noch 469 bytes. Habe mit filezilla gemacht, offensichtlich falsch....:-/

Ja ich habe SWAP sowie kleine MINI Partitionen auch alles auf der internen Sata angelegt, ist wesentlich flotter gegenüber USB.
Und auch stabil falls man doch mal CI-Module nutzt.

@dummi: FZ ist ansich nicht das Problem, wenn richtig eingestellt (und richtiger Editor) und lt. Dateigröße weicht sie nur um -1 Byte ab, nicht um +XX Bytes. Wahrscheinlich fehlt einfach nur die letzte Leerzeile bei Dir, aber dennoch müssen bei DEBUG=1 die Meldungen für jedes Modul kommen - aber eben nur seriell.

@DboxOldie: Ist zwar schneller, aber hat man eine "Valium-HDD" kann das zu Problemen führen. Zudem wird sie ja auch langsamer, wenn sie entsprechend wie von mir gezeigt benutzt wird, was dann auch für den Swap entsprechend gilt. Ansich sollte es aber dennoch in den meisten Fällen ausreichen - aber eben nur ohne "Valium".