Posts by Ghost

Und dasselbe würde auf einem Linux PC auch passieren. Nur halt später.

Da hast Du dann halt keinen audio/video decoder, an dem du irgendwas merken würdest, außer dass das ganze System langsam wird.

cu

Naja aber wie geschrieben, ist das was du da tust ja kein real life szenario.

Und erklärt wieso das passiert habe ich ja auch.

Niemand tut genau das was du da tust...

cu

Wenn die Box komplett hängt, und du nicht mehr drauf kommst, dann hilft nur mini usb. Ansonsten reicht auch die ausgabe von journalctl oder dmesg

cu

Also meine Info ist / war, dass normales Sat-IP bei Sat funktioniert.

Zu Kabel kann ich nichts sagen. Ich selber haben auch kein Sat-IP Equipment hier.

Ich meine aber gelesen zu haben, dass es durchaus Leute gibt, die das nutzen.

cu

EIn komplettes aufhängen der Box kann ich allerdings auch damit aktuell nicht nachstellen. Falls das hier jemand kann, würde ich da gerne mal Log Files von sehen. (Inklusive der Kernel Ausgaben)

Was in der Tat passiert ist, dass auch Video und Audio ggf. in dieser Konstellation dann anfängt zu stocken.

Wie gesagt. Wir schauen uns das an. Ich denke dass man das durch Einstellungen verbessern kann.

cya

Guybrush2012: sind das eigentlich Mutmaßungen deinerseits, oder hast Du das mit aktuellem Stand jeweils alles nachvollzogen? Also ja.. aktuell sind wohl Transfers über Netzwerk auf ein USB Gerät ein Problem. Allerdings ist das eher ein generelles Problem von Linux.

Am PC merkt man das nicht so krass, weil dort einfach viel mehr RAM vorhanden ist. Bei normalen Anwendungen wie Partnerbox.. oder beim abspielen von Aufnahmen von / zu einem Netzwerk FS sollte da nichts passieren. Das ganze entsteht aktuell dadurch, dass der Kernel einfach den RAM für Caches nicht limitiert. Das sieht man eben bei diesem hochladen über Netzwerk auf ein ggf. angeschlossenes USB Gerät sehr gut. Anfangs geht es sehr schnell, weil der gesamte RAM als Puffer verwendet wird. Nur irgendwann ist dieser voll. Dann ist das langsamste Glied in der Kette das USB Gerät... und nun ist der RAM voll und der Kernel arbeitet das ab. Wir sind da gerade am schauen, wie man dem Kernel dieses Verhalten abgewöhnen kann. Vermutlich gibt es da irgendwie magischen Einstellungen im sysfs / procfs. Einen Hardwarefehler kann und würde ich da auf jeden Fall ausschliessen. Beim lesen auf der Box aus /dev/zero und dann schreiben auf eine ggf. gemountete NFS/CIFS was auch immer Netzwerk Platte ist es exakt dasselbe. /dev/zero ist unendlich schnell ... im Gegensatz zu dem nachfolgenden Netzwerk. Aber das ist ja kein Praxis relevanter Test.

cu

probier mal TERM=xterm joe

Also hier läuft er...

cu

Fred Bogus Trumper: na schau mal im putty serial.txt ... da ist ein Fetter Kernel OOps ... Das mit dem BXVD_InstallDeviceInterruptCallback...

Das ist beim Init des Video Decoders... aber generell sind Kernel OOPSE ... immer ein schlechtest Zeichen.

Können zwar auch Software Fehler sein... aber in diesem Fall, da es ja vorher Ewigkeiten funktioniert hat wohl eher nicht.

Das Image hat er hoffentlich auch mal mehrfach geladen.. oder ein anderes versucht. Nicht, dass es beim Download kaputt gegangen ist. Aber das ist irgendwie auch unwahrscheinlich.

cya

Hmm die Hardware Treiber crahen beim laden. Das ist das eigentliche Problem.

Da es aber ja die ganze Zeit funktioniert hat, wird wohl ein Hardware defekt vorliegen.

cu

zombi: hmm skin.xml war noch nie ein fallback. Deshalb gibts ja die skin-default.xml... die ist fallback für alles was nicht in der skin.xml des jeweiligen Skins vorhanden ist.

cu

The Image with "rescue" in name is just used to flash a new software (tar.xz image).

However, it is normally not necessary to flash the normal software again. An online update is sufficient, and in the end it creates exactly the same software version as if you flashed the .xz again.

It is not necessary and not recommended to update the rescue image if the existing one works.

cu

Ich schiebe gleich einen Patch ins OE...

cu

@Guybrush2012: ja, genau.... mit Unicable kann sie auch 2xSat.

Es ist wie bei dem Combo Stecktuner ein dual Tuner / Demod. Aber jeweils nur ein Anschluss vorhanden.

Sprich man kann ein Sat und ein C/T2 Kabel anschliessen.

Man kann also z.b. einen Transponder über DVB-C emfangen... und gleichzeitg Sat. Oder Aber zweimal DVB-C .. oder ein/zweimal DVB-T(2).

Was nicht geht ist DVB-C und DVB-T2 gleichzeitig, weil ja nur ein Anschluss vorhanden ist.

cya

Den Fehler habe ich lokal schon behoben. Wird im nächsten Update enthalten sein.

cu

BartHD: kannst Du da mal nähere Infos liefern?

Also wie genau..... Samba... NFS... FTP ... macht das einen Unterschied?

Und hmm macht es einen Unterschied, ob der USB3 Port (blau) oder der USB2? (weiss)

Und wie groß muss die Datei denn sein?

cu

Ich habe mir das nun mal angeschaut, und den Fehler behoben.

Wird dann im nächsten Update definitiv behoben sein.

cya

Wie ich schon schrieb, hätte ich gerne mal ein komplettes Log von Anfang an. Damit man das alles ordentlich nachvollziehen kann.

Alles andere ist Rätselraten.

Ich glaube irgendwie nicht an einen Hardware defekt auf der Seite der Box.

cu

Ohne ein Logfile von Anfang an wird das wenig bringen. Also im Nachhinein, wenn der Fehler schon da ist bringt das nichts mehr.

Am einfachsten wird es sein, wenn du Dir vom Feed "screen" installierst.

Dann in einer telnet/ssh session "screen" eintippst.

Danach dann "journalctl -f > /tmp/bla.log" ausführst.

Den offenen screen kannst Du dann mit Strg-A-C beenden. Das journalctl läuft dann aber weiter. Auch wenn Du dann das telnet oder die ssh session beendest mit exit.

Sobald der Fehler dann aufgetreten ist, kannst Du das Logfile dann via ftp samba... whatever aus /tmp rausholen und ggf. gzippen und hier hochladen.

Dann kann man eventuell etwas mehr sagen. So pauschal würde ich erstmal sagen, dass der Unicable Schalter manchmal nicht schaltet, und das komische fehler verursacht. Aber ohne Logfile alles nur Vermutungen.

Übrigens muss das alles wirklich mit einem Kabel gehen. Zwei Kabel am selben FBC Tuner verursacht mehr Probleme, als es hilft. Zumindest bei Unicable.

Den laufenden screen kann man übrigens immer wieder öffnen wenn man wieder eine telnet / ssh session öffnet und dann screen -r eingibt.

Sollte es beim eingeben von screen die Meldung "clear screen capability required." geben... dann einfach "TERM=xterm screen" eingeben.

Dann sollte es auf jedenfall gehen.

cu

Ist in der Tat ein Bug, der aber anscheinend nur sehr selten Auftritt.

Ich schau es mir bei Gelegenheit an.

cya