Posts by ABPSoft

    Quote

    Originally posted by privat75


    Das selber bei der 800se


    Erstaunlich. Der TOSlink an meiner 7020HD und an meiner 800HD ist immer rot, egal ob AC3 Downmix an oder aus, egal ob Mute an oder aus, sogar egal ob im Standby oder nicht. Carrier ist also scheinbar immer da. An der 7020HD (800HD hab ich nicht gegengecheckt) kommt bei aktivem AC3 Downmix offenbar PCM raus (viel zu lautes PCM btw, woran man auch leicht unterscheiden kann, ob das natives AC3 oder PCM ist - abgesehen von der Anzeige am AV-Receiver). Bei Mute wird wahrscheinlich ein PCM-kodiertes Nullsignal gesendet, kann ich aber nicht genau prüfen (rotes Licht ist da und der AV-Receiver geht von DD5.1 auf ProLogic, was heißt dass er wohl irgendein 2.0-Signal bekommt, aber das steht selbst dann da, wenn TOSlink tot ist - kann also gut sein, dass da keine S/PDIF-Modulation mehr auf dem Carrier ist). Müsste mal jemand mit 'nem AV-RX aus diesem Jahrtausend testen, der das visualisiert :winking_face:


    Ihr müsst aber zugeben, dass es ein grober Designfehler wäre, wenn bei aktivem AC3 Downmix kein PCM auf einem S/PDIF (egal welcher PHY) rauskäme. Kann ich mir irgendwie kaum vorstellen, aber ich habe keine 8000 und auch keine 800se zum testen. Für die 7020HD sehe ich mich aber zumindest qualifiziert zu sagen: Wenn der TOSlink dunkel ist, dann ist er wahrscheinlich kaputt (aufpassen, meine 7020HD hat eine Schutzklappe vor der Polymer-"Ferrule", dass da Licht ist sieht man nur bei hinreichender Dunkelheit).


    Verwundert,
    Andre.

    Quote

    Originally posted by Doc
    aber wenn du downmix an hast kommt der ton nicht aus dem ac3..


    Ton kommt immer aus dem TOSlink, zur Not halt PCM (wenn nur MP2 vorliegt oder AC3 Downmix aktiviert wurde). Wenn's da also dunkel ist, klingt das leider sehr nach einem Defekt...


    Meine 7020HD hat da jedenfalls Rotlicht seit Sekunde 0. TOSlink ist hier der einzige Weg, wie überhaupt Ton aus der Box gelangen könnte, da muss also eigentlich immer was anliegen, wenn nicht gerade gemutet wurde.


    HTH,
    Andre.

    Quote

    Originally posted by kernm23
    kann ich beim automatischen sendersuchlauf einstellen, dass meine dm800hdse dvb-c nur die deutschsprachigen unverschlüsselten sender sucht?


    Mal orthogonal zu den bisherigen Antworten: Die Frage deutet ein wenig darauf hin, dass Du Dich mal mit dem Konzept der Bouquets, im einfachsten Fall nur den Favoriten, auseinandersetzen solltest. Der Wunsch gleich beim Sendersuchlauf zu filtern mag bei vielen DVB-Receivern naheliegend sein, aber zum Glück macht die Dreambox das richtig: Der Sendersuchlauf findet und speichert alle Sender. Aber kein Mensch navigiert in dieser Liste (außer, um mal zu gucken was sich da so geändert hat), sondern stellt sich Favoriten-Sammlungen zusammen. Die enthalten dann genau das was man haben will, nichts was man nicht haben will, und alles in der gewünschten Reihenfolge. Und all das bleibt auch bei zukünftigen Sendersuchläufen erhalten. Wenn man sich an diese Flexibilität gewöhnt hat (und daran, dass die Favoriten/Bouquets nicht kaputt gehen), dann braucht man keine Filter mehr.


    HTH,
    Andre.

    Hi,


    geh mit telnet auf die Box (Nutzername root, wenn Du noch nie vorher drauf warst dann leeres Passwort), dann:


    Code
    cd /media/hdd
    rm *.ts


    Und schon sollte wieder Platz sein.


    HTH,
    Andre.

    Quote

    Originally posted by ernsth77


    root@dm8000:/# fsck.ext3 /dev/sda1
    e2fsck 1.41.9 (22-Aug-2009)
    /dev/sda1: clean, 1430912/1430912 files, 214324927/366284008 blocks


    Deine i-nodes waren komplett belegt. Kannst Du mit "df -i" verifizieren. Hint: Klassische UNIX-Filesysteme haben eine beim Anlegen festgelegte Anzahl von i-nodes, d.h. maximale Anzahl von Files, die man erzeugen kann. Bei Filesystemen für TV-Aufnahmen ist das erwartete Nutzungsverhalten klar "wenige, dafür sehr große Files" und man legt eher weniger i-nodes an - der Platz ist besser für Datenblöcke aufgehoben. Bei typischen Allzweck-FS wird von einem Daten-i-node-Verhältnis von 16KiB oder sogar weniger ausgegangen, Dein FS optimiert für - wie Du nachrechnen kannst - durchschnittlich 1MiB pro i-node. Du hast es dann einfach komplett gegen den Strich gebürstet :winking_face:


    HTH,
    Andre.

    Quote

    Originally posted by hans_wurst71
    Super, danke dir ABPSoft! Läuft einwandfrei auf der 7025. Auf der 7020HD habe ich's noch nicht ausprobiert.


    Fein. Gebacken habe ich das übrigens in einem Tree für die dm800, aber so lange alles mipsel ist und nichts boxspezifisches ins Spiel kommt...

    Quote

    Mit Bitbake hatte ich noch keinerlei Berührungspunkte. Kompiliert habe ich bisher nur auf meinem Ubuntu-Server. Habt ihr einen Link zu einem soliden How-To?


    Ich habe damals eigentlich primär die Development-Foren hier ein wenig quergelesen, speziell http://www.i-have-a-dreambox.com/wbb2/board.php?boardid=262 und http://www.i-have-a-dreambox.com/wbb2/board.php?boardid=264 waren hilfreich. Es geistert wohl einerseits ein Script für Debian bzw. Ubuntu rum, der versucht alle möglichen Dependencies zu installieren und das System zu preppen, aber der machte mir zu viel hidden magic (z.B. /bin/sh auf /bin/bash verlinken, was ich im Kontext nachvollziehen kann, dann aber lieber selbst mit "dpkg-reconfigure dash" mache statt an der Distri vorbei). Andererseits gibt es unter http://git.opendreambox.org/?p…e-opendreambox.git;a=tree ein passendes Makefile für OE1.6, das - vorausgesetzt man hat die restlichen Voraussetzungen - sich ausschließlich darum kümmert, einen OE-BuildTree auszuchecken und einem so den Start erleichtert, ohne dass einem alles aus der Hand genommen wird. Ich bin mit dem Makefile zum Ziel gekommen. Ich mach das aber nicht, um ein komplettes Image zu bauen, das ich dann auch laufen lasse, sondern eher, um an einzelnen Tools rumzubasteln oder Sachen zu bauen, die nicht vorgesehen waren (memtester, binutils etc).


    Über How-Tos stolperst Du auch in den Developer-Foren, aber AFAIR geht's da primär um das Script.


    HTH anyway,
    Andre.

    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 :winking_face:


    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 :winking_face:


    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 :winking_face:


    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...