Posts by ABPSoft

    Quote

    Originally posted by kenatonline
    Bitte NICHT "root_squash" setzen, sondern beim "no_root_squash" bleiben.
    Mit "root_squash" werden alle Dateien von root auf nobody gemappt. Das gibt
    dann bei Zugriffen ueber SMB/CIFS Probleme.


    Oh Gott, wie konnte ich das übersehen. Da steht root_squash statt no_root_squash, und ich zitier das auch noch, als wär's richtig. Ich konnte mir nicht vorstellen, dass jemand die Option, die hier garantiert nicht hilft (und außerdem default ist), explizit reinschreibt und habe das unterschwellig als no_root_squash gelesen. Mea culpa.


    Jetzt mal das Posting editieren, damit da kein Blödsinn verewigt bleibt...


    ISC,
    Andre.

    Quote

    Originally posted by cooli81
    Habe mit Netscan den mount gefunden und auch in die automount eingegeben. Wenn man dann dort auf den Button "Geschwindigkeit Testen" geht, kommt "Ordner kann nicht erstellt werden" - das ist doch ein Zeichen, dass wohl entweder der Mount nicht korrekt ist oder eine richtige Freigabe fehlt.


    Oder dass er ReadOnly ist...


    Quote

    Muss man nicht irgendwo auf der Nas die Dreambox eintragen, damit die dann auch Zugansberechtigungen bekommt? Den bei der Dreambox muss ich ja nirgends Zugangsdaten der NAS eingeben.


    NFS (<4) funktioniert etwas anders. Hier wird vorausgesetzt, dass der Zugang bereits anderswo geklärt wurde, das NFS selbst benutzt nur die resultierenden User-IDs, die auf Client und Server zusammenpassen müssen. Da die Dream aber eh alles als root macht und UID 0 universell gleich ist, klappt das hier - vorausgesetzt man schaltet den Sicherheitsmechanismus aus, der root normalerweise komplett aussperrt (aus gutem Grund, das zu erklären wird aber hier zuviel). Das macht die exports-Option no_root_squash. Also Dein:


    /mnt/disk/volume1/volume1/Dreambox/Movie *(ro,root_squash,sync,no_subtree_check)


    Heißt: Exportiere den Pfad (wieso ist da eigentlich volume1 doppelt drin?) an jede beliebige IP-Adresse, erlaube root dabei aber keinen Zugriff (da steht root_squash, d.h. der Sicherheitsmechanismus ist an!), und dieser Teilbaum bleibt außerdem ReadOnly. Glaube nicht, dass Du das so wolltest...


    HTH,
    Andre.


    Edit: Völlig übersehn, dass da bei cooli81 root_squash steht statt no_root_squash. Übrigens bei allen Exports, d.h. da wird nicht viel gehen, es sei denn der NAS hat ein sehr seltsames Handling von NFS-"nobody".

    Quote

    Originally posted by wega78


    hab ich gemacht. fehler ist aber noch da.


    Dann hast Du noch nicht das richtige Zertifikat erwischt. Ich kenn das Drama, solche Certs verstecken sich irgendwo zwischen den hunderten CAs und sind leicht zu übersehen. Besonders putzig ist es, wenn sie für APIPA-Adressen gebaut werden, man hat dann keinerlei Chance, das irgendwie sauber zuzuordnen (wenn mehr als ein Gerät der selben Sorte im Spiel ist). Zur Not alles löschen, was nicht nach 'ner offiziellen CA aussieht...

    Quote

    Originally posted by hans_wurst71


    ich hätte gern einen Terminal Multiplexer auf meinen Dreamboxen (7025+ und 7020HD). Also sowas wie GNU Screen zum Beispiel. Da soll es wohl auch ein fertiges ipkg-Paket geben. Bin aber nirgends fündig geworden. Hat jemand eine Idee?


    Screen fällt im OE 1.6 ohne weitere Maßnahmen bei "bitbake screen" einfach runter. Von 7025+ habe ich allerdings keine Ahnung. Ich häng das ipkg mal an, aber keinerlei Garantie für irgendwas (es baut, mehr ist nicht getestet).


    HTH,
    Andre.

    Quote

    Originally posted by freebsd-man
    Ich habe das Problem nicht.
    Somit wird es wohl nicht am iCVS oder GP3 alleine liegen.


    Könnte 'ne race condition sein. Das last_access wird offenbar nicht im Konstruktor von Harddisk initialisiert, sondern erst in startIdle(). Und das auch nur, wenn isRemovable nicht wahr ist. Also entweder kommt der Skin da zu zeitig, oder er fragt das für einen USB-Stick an oder sowas (der isRemovable-Test kam am 10.2. dazu und ich habe einen USB-Stick an der DM800). Alles natürlich nur geraten, ich kenn den Code nicht wirklich, kam mir nur grade beim Stöbern im GIT vor die Flinte. Der Renderer, der das triggert, sollte wohl besser abfangen, wenn das Attribut (noch) nicht gesetzt ist.


    Spekulierend,
    Andre.

    Quote

    Originally posted by wega78
    Ihr Zertifikat enthält die gleiche Seriennummer wie ein anderes Zertifikat dieser Zertifizierungsstelle. Bitte erwerben Sie ein neues Zertifikat mit einer eindeutigen Seriennummer.


    (Fehlercode: sec_error_reused_issuer_and_serial)


    Das ist ein Klassiker bei Firefox, der merkt sich einmal gesehene Zertifikate und weigert sich bei Self Signed Certs mit exakt den Daten eines Certs, das er schon gesehen hat, das aber für einen anderen Key ist, irgendwie weiter zu kommunizieren. Das ist im Prinzip Ok, weil es Dich gegen Rogue CAs schützt, aber sehr unpraktisch bei Embedded Devices, die ihre eigenen Self Signed Certs erstellen, die nach jedem Factory Reset zwar gleich aussehen, aber andere Keys haben.


    Lösung: Im Browser die Zertifikatverwaltung finden und das verursachende Zertifikat löschen. Ist manchmal schwer zu finden, bei Dreams sollten der Hostname (dmNNN...) oder die Organization "Dreambox" auftauchen. Manchmal hängen solche Certs auch nur an der IP-Adresse. Wenn das alte Cert raus ist, die Exception für das neue akzeptieren und alles ist wieder gut.


    HTH,
    Andre.

    Quote

    Originally posted by bodyslider
    @ ABPSoft


    jepp, wäre cool, wenn du noch was finden würdest ;)


    Naja, in A/52:2010 findet man nicht wirklich was Definitives, weil der Standard sowohl das Interface der Datenquelle in den Decoder als auch das PCM Output Interface absichtlich nicht spezifiziert. Input kann continuous oder bursty sein, aligned oder unaligned, der Decoder sollte damit zurechtkommen und hat höchstens ein paar Probleme, gleich beim ersten Frame richtig zu syncen. Die möglichen Reaktionen auf Fehler (fehlende Frames sind letztlich auch ein Fehler, so wie Sync Fehler oder CRC Fehler im Stream) sind ebenfalls nicht spezifiziert, d.h. der Implementation überlassen. Der Standard benennt nur ein paar, nämlich Muting, Block Repeats und Frame Repeats. Generell erwartet der Standard, dass die Ingenieure, die ihn implementieren, das Richtige tun, was sich am klarsten im Enhanced AC-3 Annex findet (in einem etwas anderen Kontext):


    Quote

    E3.1 Glitch-Free Switching Between Different Stream Types


    Enhanced AC-3 decoders should be designed to switch between all supported bit stream types
    without introducing audible clicks or pops.


    Wie das in der Praxis gehandhabt wird, müsste jemand sagen, der sowas implementiert, am besten konkret für S/PDIF.


    Generell wird hier wohl Jon Postels Robustness Principle auf beiden Seiten verletzt: Weder ist der E2-Receiver konservativ bei dem was er sendet, noch ist Dein PreAmp liberal bei dem, was er entgegennimmt. Und dann kanns krachen (bzw. knacksen).


    Andre.

    Quote

    Originally posted by Dog6574


    Ich habe mit dem neusten ICVS 22.11. immer wieder GS. Ich nutze eine DM8000 mit 4 Tunern und einer 2TB Platte. Crashlog hänge ich an.


    Wer kann helfen?


    Ich kann nich helfen, nur den exakt selben Crash bestätigen. Ging bei meiner DM800HD los, nachdem die letzten Updates eingespielt wurden. E2 startet, läuft ein paar Sekunden und GSed dann. Ich vermute, der Skin will in der Infobar den Festplattenzustand anzeigen und benutzt dazu ein API, das im iCVS nicht drin ist (AttributeError: Harddisk instance has no attribute 'last_access'). Ich hab erstmal in der Shell den dmm-HDr2 deinstalliert, danach war es weg. Google hat damals (war letzte Woche) rein gar nichts gefunden, aber offenbar bin ich mit dem Fehler nicht (mehr) allein.


    HTH anyway,
    Andre.

    Quote

    Originally posted by bodyslider


    Allerdings bin ich schon enttäuscht davon, dass ich beim Umschalten der TV-Sender ein starkes Knacksen in den Boxen habe. Dies geschieht auch zum Beispiel dann, wenn ich bei einer DD-Wiedergabe auf Pause drücke. Hatte das gleiche Problem auch mit einer VU Ultimo


    Ich hatte weder mit meiner DM800HD irgendein Knacksen, noch habe ich es jetzt mit meiner DM7020HD. Die Verbindung zum AV-Receiver geht hier z.Z. noch über S/P-DIF (TOSlink), selbstverständlich nativ (kein Downmix).


    Wenn Du den Effekt schon mit zwei Zuspielern hattest, vielleicht liegt das Problem auf der anderen Seite des Kabels? Knacksen klingt eigentlich wie nicht abgefangene Pegelsprünge, wenn ein AC3-Frame noch vom alten Sender kommt und das nächste schon vom neuen, oder wenn der AC3-Strom kurz oder länger aussetzt (Pause). Zumindest das Aussetzen sollte eigentlich sauber vom Decoder abgefangen werden, und so schnell, dass nicht zusammengehörige AC3-Frames back-to-back rausgehen würden, zappt die Dream nun auch wieder nicht. Ich gebe zu, dass ich nicht weiß, ob es in solchen Fällen zum guten Ton gehört, dass der Zuspieler dann aktiv ununterbrochen AC3 Silence Frames produziert. Muss mal den Standard rauskramen, falls ich den wiederfinde...

    Quote

    Originally posted by diveluke


    sorry, so ganz verstehen kann ich es nicht, das CI muss mindstens 2 "Transponder" entschluesseln koennen. sonnst koennte der PVR die filme ja nicht entschluesselt auf der hdd ablegen. auch wenn es sich um den gleichen sender/transponder handelt. Tuner 1 fuer die aufnahme, tuner 2 fuer die entschluesselung.


    Nein. Ein Tuner demoduliert einen ganzen Multiplex. Bei Sat nennt der sich auch Transponder, bei Kabel/Terrestrisch sagt man eher Kanal. Der Multiplex enthält mehrere Sender (jeder "Sender" ist ein Bündel aus zusammengehörigen Elementary Streams für Video, Audio, TTX etc) in einem Transport Stream und wird als ganzes über den CA-Modul im CI gejagt, der damit prinzipiell jeden Sender im Multiplex parallel dekodieren kann, aber eben keine Sender aus einem anderen Multiplex - die kommen bei ihm gar nicht vorbei. So lange die Sender im selben Multiplex stecken, kannst Du also prinzipiell alle davon aufzeichnen und sehen (Limit ist die Bandbreite der Festplatte, die Anzahl von Videoausgängen der Hardware [think PIP], dummerweise aber meistens die Blödheit oder Bösartigkeit der Hersteller, also unabsichtliche oder gar absichtliche Kundengängelung).


    Es gibt übrigens einige Receiver, die diesen Designfehler des CI umgehen, indem sie alle von den Tunern kommenden Multiplexe demuxen, die relevanten Elementary Streams wieder neu zu einem künstlichen Multiplex zusammenmuxen und das Resultat dann durch den CI/CA jagen. Das geht, ist aber enorm aufwendig (speziell wegen der umzumodelnden Metadaten), CPU-lastig, skaliert nicht beliebig und ist einfach hässlich. Jedenfalls für uns, die wir eine bessere Lösung kennen. Suchbegriffe hast Du ja schon.


    HTH,
    Andre.

    Quote

    Originally posted by MacDidi
    So, da ich bei einem Kumpel mit dem gleichen Problem kämpfe: ich komme nicht zu DHCP und IP:
    Seit SSL 86 kommt man mit der Programm-up-Taste zu DHCP und IP und kann dann ganz normal flashen?


    Seit SSL85. Das war ein Bugfix, denn das sollte eigentlich schon immer mit dieser Taste gehen, so ist es dokumentiert. Wahrscheinlich, weil man sonst sehr leicht in den STOP kommt, wenn man beim Anschalten lange auf die Power-Taste drückt. Ich fand das ja viel besser ;)


    Quote

    Dann war unser "Fehler" also, dass wir ein Softwareupdate gemacht haben, danach SSL 86 drauf war oder wie?


    Ihr habt gar keinen Fehler gemacht, der Fehler lag bei DMM. Die haben ein Update veröffentlicht, das gleichzeitig online auf den SSL86 updaten wollte und etwas im Bootvorgang des Kernels geändert hat, das dringend auf SSL86 angewiesen war. Nur hat das online Update auf SSL86 gar nicht funktioniert (ich hab's auf der Shell gemacht, es war nix zu sehen vom Flashen des SSL). Die Kiste stand hinterher also immer noch mit SSL85 da und konnte den Kernel nicht mehr laden. Da SSL85 aber noch sauber funktionierte, hat es gereicht, nur den SSL86 aus dem STOP einzuspielen, dann bootete sogar das Image. Neuflashen des Image war also unnötig. Ich hab das auch nur gemerkt, weil ich nach dem Flashen von SSL86 nicht schnell genug war, die richtige Taste für STOP zu drücken ;)


    HTH,
    Andre.

    Hi,


    Dateien umbenennen zu müssen ist immer noch irgendwie umständlich. Eigentlich bräuchte man für solche Fälle einen unabhängigen und leicht zu manipulierenden Metadaten-Mechanismus, um eine Aufnahme als 3D zu markieren. Den haben wir sogar schon. Lässt es sich machen, dass ein Tag "3D" an einer Aufnahme immer zum Override der Erkennung anhand von Sendername/Dateiname führt? Man könnte soweit gehen, optional Tags der Form "3D:Mode" zu supporten, etwa "3D:SideBySide" vs. "3D:TopBottom", weggelassener Mode nutzt den Default. Nur so 'ne Idee.


    Andre.

    Hi,


    interessante Idee, Jabber auf der Dream. Ich hatte hier gerade einige Probleme, mit meinem Server Kontakt aufzunehmen. Der Grund ist, dass das Plugin wohl kein STARTTLS spricht und so gar nicht erst rein kommt, wenn der Server das erzwingt. SSL auf 5223 ist Legacy und in neueren Installationen meistens zu. Erst mit extra aufgemachtem Legacy SSL im Server ging's dann. Das dürfte viele Konnektivitätsprobleme erklären.


    BTW, sehe ich das richtig, dass man selbst bei einem internen Server mit fertigen Buddies und Shared Roster Groups nix zu sehen kriegt, bevor man nicht manuell Buddies hinzufügt? Ist sicher am Betrieb mit riesigen öffentlichen Jabber-Servern orientiert, wo man unmöglich alle Nutzer sehen will. Nur irgendwie seh ich rein gar nix. Messages kommen aber an, wenn ich "Zeige Nachricht" einstelle.


    Gespannt, wohin sich das entwickelt,
    Andre.

    Quote

    Originally posted by Kante2k
    Warum seid ihr alle so Heiss auf ext4, btrfs gehört die zukunft!


    Aber nicht für Video Storage auf Set Top Boxen. Das fragmentiert doch in kürzester Zeit wie blöde (gut, das tut bei diesem usage pattern praktisch jedes FS, nur BTRFS besonders heftig). Dagegen ist ext4 inzwischen schon halbwegs abgehangen, kann auf Wunsch auch ohne Journal laufen (800HD-User wird's freuen) und frisst moderat Ressourcen (RAM). Und bigalloc passt auf unseren Anwendungsfall wie die Faust aufs Auge - ich nehme mal an, 64KiB als Metablockgröße bringen zusammen mit delayed allocation einiges an Ruhe rein (speziell weniger interleave fragmentation bei mehreren gleichzeitigen Aufnahmen, wenn man sich das bei ext2/3 mal mit filefrag anguckt, sieht das schon sehr ungesund aus).


    Generell gibt's schon lange ein FS, das besser geeignet wäre als ext2/3 und zu dem erst ext4 aufschließen konnte. Aber Gutemine hat sich ja schon ausgiebig damit ausgetobt und war von XFS auf der Dream damals nicht begeistert. Schon da war der RAM ein Problem, und wirklich stabil war's wohl auch nicht. Andererseits nimmt fast jedes embedded storage device auf Linux-Basis intern XFS, sei es ein QNAP oder mein Samsung-TV. Habe nie verstanden, wieso das bei Dreams so stiefmütterlich behandelt wurde. Naja, RedHat hat XFS ja auch erst seit kurzem lieb...

    Quote

    Originally posted by _pustekuchen_
    warum steht den die Hitachi 2mal da ?


    Du siehst zwei Symlinks auf Device Nodes, einen für die komplette Platte (der auf sda zeigt) und einen für die erste und einzige primäre Partition auf dieser Platte (Link endet um das kenntlich zu machen mit -part1 und zeigt auf sda1).


    HTH,
    Andre.

    Quote

    Originally posted by _pustekuchen_
    nur was mach ich wenn sie im Gerätemanager nimmer erscheint?


    Einloggen und mit

    Code
    ls -l /dev/disk/by-id/


    und

    Code
    cat /proc/scsi/scsi


    nachsehen, ob die betreffende Platte noch beim Kernel bekannt ist. Am besten nach einem Power Cycle. Wenn da nix mehr kommt, dann wird's ernst.


    HTH,
    Andre.

    Quote

    Originally posted by Bschaar
    hat er,


    heute im IRC, 3.2.x wenn ich richtig gelesen hab ;)


    Allein schon wegen ext4 bigalloc wäre alles andere auch fragwürdig. Der 2.6.18 ist inzwischen so alt, dass man ihn einschulen könnte, 2.6.39 nähert sich dem ersten Geburtstag. Wenn schon ein aktueller Kernel, dann der heute aktuelle. Wird so oder so abenteuerlich, die ersten Monate werden sicher "Interessante Zeiten".

    Quote

    Originally posted by pepo83
    Joa man kann laut Manual wohl auch noch mit:
    dd if=/dev/urandom of=/dev/hda
    zusätzlich Random zeichen drüber schreiben.


    Das /dev/urandom ist nicht gerade schnell, zumal auf der DM800. Nimm /dev/zero.


    Quote

    Aber denke einmal alles mit Nullen überschreiben sollte für meine Zwecke schon reichen. So sensibel sind die Daten ja auch nicht, will eben nur nicht das man die sofort mit einem 0815 Tool gleich wiederherstellen kann.


    Bei heutigen Platten reicht ein Zero-Write völlig aus. Heise hat das mal getestet - einmal genullt und an diverse exzessiv teure Datenretter weitergegeben. Niemand konnte was retten. Die Vorsichtsmaßnahmen (mehrfach mit wechselnden Zufallsdaten überschreiben) stammen alle aus einer Zeit, als man die Bits auf den Platten noch mit einer Stecknadel treffen konnte. Die Physik ist dort heute eine ganz andere (GMR, perpendicular domains etc). Aktuelles aus den Labors der Spooks hört man natürlich nicht ;)


    BTW, wenn es schnell gehen soll (was bei dem lahmen SATA der 800 eh relativ ist), nimm gleich eine vernünftige Blockgröße. Also letztlich:

    Code
    dd if=/dev/zero of=/dev/sda bs=1m


    HTH,
    Andre.

    Hi,


    meine DM800HD-C hat im letzten Jahr eine zunehmende Anzahl von Enigma2 Crashes (Greenscreens) hingelegt, die im Crashlog ungefähr so aussehen:

    Es ist vorher keinerlei Verursacher auszumachen und auch wenn es nicht klar aus dem Crashlog hervorgeht, ist das wohl ein Segfault, Bus Error oder anderweitig fatales Signal. Die Stelle im Code ist in der libpython2.6.so und ich bin so weit gegangen, das zu disassemblieren und gegenzuchecken, ja der Code der im Crashlog steht ist genau dort, aber es ist nicht offensichtlich, wieso der faulted, außer vielleicht durch einen Stack underrun. Mysteriös ist nun folgendes:

    Man beachte die relativ starke Häufung von Crashes bei Adressen, die auf 0x1484 und später 0xb484 enden. Sieht sehr nach einer Page aus, die beim Softwareupdate leicht verrutscht ist, aber vielleicht immer auf den selben Page Frame zeigt. Die Funktion in libpython, wo es jetzt kracht, ist übrigens nicht mehr die selbe, die Stelle im Code komplett anders. Nur der PC korreliert auffällig.


    Was tun?


    Der Gedanke, es könne ein RAM-Fehler sein, liegt nicht allzu fern. Und damit die Frage: Gibt es einen Memory Tester für Dreamboxen, der geeignet ist, sowas einzugrenzen? Ich denke an ein Stück Software vom Schlage von memtest86(+), also anzubooten anstelle eines Kernels, der low level den kompletten RAM so lange malträtiert, bis man was findet - oder es satt hat. Leider finde ich nichts derartiges. Das einzige, was mir unterkam, ist memtester - habe ich mir mal im OE gebacken. Der läuft im User Mode, also vorher alles gekillt, was nicht bei -15 auf den Bäumen war, damit kriege ich auf der 800er gerade so 121MiB RAM frei. Dann 24h lang memtester drüber:

    Hmm. Kann man dem Frieden trauen? Die Crashes treten meist im Abstand von Wochen auf, manchmal häufen sie sich, gefühlt besonders wenn ein HD-Sender aktiv gesehen wird (da gabs auch mal mehrere innerhalb von drei Stunden), aber dann geht's wieder wochenlang gut. Irgendwie kein klares Muster. Als es im Sommer mehr wurde, lag der Gedanke an Temperatur nahe, aber die Kiste ist eigentlich kaum handwarm...


    Also, kennt jemand einen Memory Tester, der mehr reißt als memtester? Oder andere Ansätze zur Fehlereingrenzung für solche Fälle?


    TIA,
    Andre.