Posts by ABPSoft

    Hi,


    wenn ich das so lese, dann verzichte ich mal lieber auf das Update, bis der nächste Tarball mit dem Fix kommt. Wobei das spannenderweise niemanden sonst hier zu erwischen scheint? Wäre interessant zu wissen, was genau das triggert...


    An"paranoia"dre.

    Quote

    Originally posted by Frankster
    Am PC gibt es keine Probleme.


    Womit? Mal einen Player probiert, der auch libdvdnav verwendet? Könnte z.B. VLC sein (ich weiß nicht, wie das unter Windows aussieht - unter Linux nutzt fast alles, was DVD abspielen kann, diese Bibliothek).


    Sowas ist meist ein Corner Case im Mastering des Menüs der DVD, der auf einen Bug in libdvdnav trifft, oder umgekehrt. Nicht umsonst ist eine typische Formulierung im Changelog der Entwickler:

    Quote

    ... improved playback of badly mastered or "copy protected" DVDs.


    Wie's aussieht benutzt die Dream libdvdnav 4.1.2, was im April 2008 released wurde. Danach gab es mehrere Major und Minor Releases, die 4.2.1 ist wohl der aktuell verbreitetste Stand, nach dem Umzug ins VideoLAN Git gibt es aber seit einigen Wochen auch eine 4.9.9 - was ich mal als Anzeichen werten würde, dass man da "in Bälde" vor hat, eine 5.0 zu releasen.


    Es könnte also sein, dass Dein spezifisches Problem in einer aktuelleren Release gefixt ist - muss aber nicht. Das DVD-Bediensystem ist eine komplette VM mit einer Hand voll Befehlen, da kann immer noch irgendwo ein Corner Case sitzen und libdvdnav war seinerzeit berühmt dafür, nicht gerade frei von Glitches zu sein. Ist auch Mist, wenn man dauernd um Nasen drumrumprogrammieren muss, die versuchen, die Menü-VM mit Kopierschutz-Maßnahmen zu verseuchen (CSS selbst ist ja irrelevant).


    HTH,
    Andre.

    Quote

    Originally posted by Thorsten020
    Jetzt interessiert mich wo der Abschwächer sitzt. Vielleicht in diesen BKS Adaptern? Oder in der BKS Hausverdrahtung? Die Gesamtkabellänge incl. BKS ist schon recht lang, länger als in meiner bisherigen Wohnung. Aber der Anteil davon, der frei herumliegt ist kürzer. BKS behauptet die Qualität wird durch deren Leitungsverlegung besser. Doch die Koaxialkabel von BKS sind definitiv viel dünner.


    Ist das überhaupt Koax? Ich hatte das so verstanden, dass BKS (für mich hieß das bisher Blitzknallsatz) diesen abenteuerlichen Weg geht, mittels Baluns von Koax auf Twisted Pair umzusetzen, wobei TP-Kabel mit kaum noch realisierbaren Eigenschaften zum Einsatz kommen. Die nennen sich dann gern Cat7 (kein offizieller Standard), Cat7+ oder wie hier Kat8 (Fantasy). Das Problem: Sat-ZF liegt zwischen 1 und 2GHz und in diesem Frequenzbereich dämpft TP viel mehr als Koax. Dazu kommt, dass die TP-Kabel, die das überhaupt packen, so Space Age sind, dass sie schon kaputt gehen, wenn man sie schief anguckt. Wenn jemand drauf gelatscht ist, sind sie mit Sicherheit hinüber. Das Auflegen auf die proprietären Stecksysteme ist auch eine Kunst und Fehler sind nur mit teurem, ebenfalls proprietärem Messequipment nachzuweisen.


    Dämpfung ist (in gewissem Rahmen, diese Konstrukte sind allerdings schneller bei 30dB als einem lieb sein kann) normalerweise aber kein Problem, speziell keines, was Du mit der SNR-Anzeige zu sehen bekommst (AFAIK zeigt die Dream bei DVB-S keinen Pegel an, bestenfalls eine AGC, aus der man grob entnehmen kann, wie hoch der Vorverstärker aufdreht). Für eine massive Verschlechterung der SNR müssen (wenn nicht gerade so viel gedämpft wird, dass das Signal im Restrauschen ersäuft) andere Dinge dazu kommen, z.B. Crosstalk oder ein kaputter Balun. Insofern kann es nicht schaden, die Einzelteile der Verkabelung genauer unter die Lupe zu nehmen. Meine erste Frage wäre, ist das Zeug (Baluns) wirklich für Sat-ZF gemacht? Die für BK müssen nur bis 900MHz gehen und dürfen galvanisch entkoppeln, die für Sat-ZF tunlichst nicht.


    HTH,
    Andre.

    Quote

    Originally posted by F_brandt
    Ist eine Dreambox von der Hardware her in der Lage gemäß dieser Norm als Client (oder Server) zu laufen?
    Wenn ja, geht das schon oder fehlt evtl. noch Software hierfür?


    Die Hardware ist prinzipiell geeignet, sowohl als Client als auch als Server zu arbeiten. Die Grenzen sind hier primär bei der NIC zu suchen, die 100Mbps aller z.Z. erwerbbaren Modelle skalieren da nicht beliebig, aber auf der Clientseite doch ganz ordentlich.


    Die Software ist untenrum auch schon vorbereitet, wie man an obigem (funktionierende Bouquet-Einträge) ja schon sehen kann. Das eigentliche Problem ist, dass SAT>IP ein Paradigmenwechsel ist - plötzlich wird aus jeder Box eine n-Tuner-Box (mit unbekanntem n), ob noch was frei ist entscheidet sich erst wenn man den Server danach fragt, es kommt eine ganze Welt neuer möglicher Fehlerbilder dazu etc. Und da fragt sich, was von DMM diesbezüglich kommt - schließlich finanzieren die sich über den Hardwareverkauf. Mit Zero-Tuner-Boxen, die bezüglich paralleler Aufnahmen eine 7020HD oder 8000 in den Schatten stellen könnten, zerfällt der ganze etablierte Markt. DMM hat ja (AFAIK) auch keine Anstalten gemacht, sich in den Headend-Markt für SAT>IP zu stürzen. Ein sofortiger Einstieg in diesen Markt (also vor zwei Jahren) mit einer Palette von Headends und Zero-Tuner-Clients hätte da vielleicht komplett frischen Wind gebracht, aber er ist halt nicht passiert (oder wenn Goliath so was werden sollte, dann wurde es zu lange zurück gehalten). Da Partnerbox incl. Remote Streams ja schon länger funktioniert, hatte man wohl auch nicht direkt sofort Handlungsbedarf gesehen. Dabei kommen einem sofort coole Ideen, wenn man drüber nachdenkt - wenn alle Dreamboxen am LAN automatisch ein SAT>IP-Cluster aus allen vorhandenen Tunern bilden würden, das dann wiederum allen zur Verfügung steht, und das am besten auch gleich Quellenneutral (DVB ist auch -C und -T)...


    Anders gesagt, keiner weiß was (von DMM) kommt und ob es gut genug sein wird, um sich komplett in SAT>IP zu stürzen und das olle Koax endlich loszuwerden.


    HTH,
    Andre.

    Quote

    Originally posted by Superposchi
    Leider habe ich jetzt zu wenige von diesen n/a-Einträgen im Bouquet, deshalb die Frage wie und ob überhaupt man solche Einträge manuell erzeugen kann?


    Guck Dir an, wie ein solcher n/a im Bouquetfile selbst aussieht, editier das File, duplizier diese Zeile und lade dann das Bouquet neu übers WebIF (oder mach einen E2 Restart). Oder guck mal, ob sich einfach der letzte Sender in einem Deiner Blöcke so oft duplizieren lässt, dass der Block aufgefüllt ist. Irgendwie ist das sicher hinzukriegen, und ob das jetzt Sinn ergibt oder nicht ist Geschmackssache. Wenn Du als erstes das originale Bouquetfile beiseite kopierst, ist auch wenig kaputt zu kriegen, zur Not kopiert man das halt zurück.


    HTH,
    Andre.

    Quote

    Originally posted by netdom
    An sich funktioniert es, aber leider nicht im Cron. Habt ihr eine Idee woran das liegen könnte ?


    Sowas liegt eigentlich immer daran, dass Cron nur minimale Suchpfade (PATH) setzt, woraufhin dann diverse Kommandos nicht gefunden werden.


    Bash
    #!/bin/sh
    #set -x
    /bin/date > /media/hdd/dyndns/file.txt


    Wenn Du hier stattdessen sowas wie

    Code
    exec >/media/hdd/dyndns/log-`date +%Y%m%d%H%M%S`.txt 2>&1


    hinklebst, hast Du ein vernünftiges Log. Wenn Du dann noch Dein obiges set -x (oder gleich set -xv) scharf machst, auch mit Debug.


    Code
    DATA=$(/usr/cat /media/hdd/dyndns/update.api | ...


    /usr/cat? Siescheer dat?


    Quote

    Das ist mir auch schon mit anderen Scripten so gegangen, ich versteh es nicht.


    Es ist eigentlich immer ein Pfad - oder etwas, das beim Versuch, die Pfade absolut zu machen, schief ging. BTW, man kann den PATH auch im Script als allererstes aufblasen, dann spart man sich das rumfriemeln an jedem einzelnen Befehl ;)


    HTH,
    Andre.

    Quote

    Originally posted by arcade
    BusyBox v1.19.4 (2013-06-03 21:22:04 CEST) multi-call binary.


    Usage: tune2fs [-c MOUNT_CNT] [-i DAYS] [-L LABEL] BLOCKDEV


    Wuargh. Mir war nicht klar, dass selbst die e2fsprogs in einer von BusyBox lobotomisierten Version beiliegen. Man könnte jetzt die richtigen e2fsprogs für OE2.0 bauen, ich hab sowas mal früher für OE1.6 gemacht, um an filefrag und e2freefrag ranzukommen, aber meine Build-Umgebung gerade nicht zur Hand. In Deinem Fall ist die Lösung aber einfach: Da es externe Platten sind, hängt man die einfach kurz an einen richtigen Rechner auf dem Linux läuft (zur Not halt ein Live-System booten, ich empfehle GRML), setzt den Befehl ab und hängt sie wieder an die Dream.


    HTH,
    Andre.

    Quote

    Originally posted by abero
    Jetzt konnte ich vorher jedoch noch ein 250MB großen RAW-Dump namens 'FLASH' (ohne Endung) auf den PC sichern. Gibt es irgendeine Möglichkeit aus der Datei noch Config-Dateien zu extrahieren?


    Im Prinzip ja. Man müsste den konkreten Abschnitt mit dem UBIFS von / lokalisieren und dann auf einer Hostmaschine mit nandsim und UBIFS im Kernel das Filesystem mounten. Wie das prinzipiell geht, ist hier angedeutet. Das liest sich aber, als sollte man da einigermaßen wissen was man tut oder man kann sehr viel Zeit zubringen...


    Quote

    Das ich es nicht zurückflashen kann ist mir klar ;)


    Das ist eine besonders spannende Frage (nicht in Deinem Fall, das Ding würde ja dann wieder nicht mehr booten). Aber wir haben hier eine 100% bitidentische Kopie der Payload-Daten des Flashs. Im Prinzip muss man die auch wieder so in den Flash kriegen, wobei eine optimierte Schreibroutine unangetastete Erase-Blocks identifizieren und nicht sinnlos überpinseln sollte. Also eher nicht sowas wie dd nach /dev/mtdblock3 ;)


    HTH,
    Andre.

    Quote

    Originally posted by pepo83
    Also bei mir hat das Defragmentieren nicht viel gebracht:
    vorher 90%
    nachher 83%
    ?(


    Der von xfs_db ausgegebene fragmentation factor ist mit einiger Vorsicht zu interpretieren, genaues dazu sagt die Manpage. Dazu kommt:

    • Ohne weitere Parameter läuft ein Aufruf von xfs_fsr maximal 2 Stunden (oder höchstens zehn Durchläufe, wenn es schneller gehen sollte). Große und böse fragmentierte Filesysteme sind in dieser Zeit aber nicht komplett zu schaffen. Das ist kein Problem, weil die Wirkung kumulativ ist. Also nochmal aufrufen.
    • Standardmäßig sichert xfs_fsr seinen State in /var/tmp, was aufgrund der falschen Persistenzeigenschaften dieses Directories auf der Dream nicht so clever ist. Es macht allerdings auch wenig Unterschied, wenn man das bloß alle Jubeljahre mal aufruft, einigermaßen regelmäßige Runs (sagen wir mal wöchentlich) profitieren aber von der Option -f um das woanders zu parken.
    • Sehr volle Filesysteme oder solche mit bereits enormer Free Space Fragmentation werden nicht von einem Durchlauf optimal. Im Worst Case verbessert sich nichts mehr, obwohl noch jede Menge ineinander verschachtelte Kämme rumliegen. Daher am besten defraggen, nachdem man größere Löschaktionen hatte.
    • Verbose (-v) ist sehr hilfreich bei interaktivem Aufruf (man sieht dann, welche bösen Kämme mit >20000 frags man so ansammelt, und ob es bereits Probleme gibt, noch Free Space zu finden - wenn also ein File nicht bis zu einem einzigen Extent zusammengefaltet werden kann oder oft kommt, dass keine Verbesserung mehr möglich ist, dann weiß man bescheid). IMO bringt es aber gar nichts, einen Aufruf über Cron Verbose laufen zu lassen, zumal auf der Dream kein MTA läuft. Ausnahme wäre, wenn man den Log irgendwohin abwirft, um ihn später anzusehen.


    Unter dieser Maßgabe mal eine Idee für ein triviales defrag-Script, das interaktiv und unter Cron laufen sollte (ich nehm für den State /media/usb aber das kann auch im Flash oder auf der HDD liegen - rennt ja nicht aller paar Minuten, schreibt dort nur wenig und die HDD läuft sowieso):

    Code
    #! /bin/sh
    OPTS=""
    tty >/dev/null && OPTS="$OPTS -v"
    exec xfs_fsr $OPTS -f /media/usb/.fsrlast


    HTH,
    Andre.

    Quote

    Originally posted by arcade
    Warum wird bei der 6.Platte eine Auslastung von 100% angezeigt...?


    Weil die Root Reserve bereits angekratzt ist. Die Prozentanzeige des Füllstands in df ist immer relativ zur Root Reserve, die wiederum ist einstellbar. Guck dir mal an, was

    Code
    tune2fs -l /dev/disk/by-uuid/d172878f-106e-a442-1739-e7d2a3299a6c

    ausspuckt (Feld Reserved block count) und versuch, das mit tune2fs -m oder tune2fs -r zu ändern. BTW, die Root Reserve gibt es aus zwei Gründen, einer davon ist, dass ein nahezu volles FS wie blöde fragmentiert. Ich würde das vermeiden wollen, es sei denn Du nutzt das quasi nur als Archiv.


    HTH,
    Andre.

    Quote

    Originally posted by SuPerfrEa|<
    Komisch das ich dies beim Kabeltausch nicht bemerkt hatte.
    Auch die SNR, AGC und BER waren auf beiden Tunern im grünen Bereich.... :rolleyes:


    Wenn der F nur noch lose auf dem Schirm hing, war das der ZF sicher ziemlich egal (die koppelt auch schon mal weitgehend ohne Masseschluss aus), aber der Widerstand für niedrige Gleichspannungen dürfte deutlich hoch gegangen sein, so dass dieser Tuner den LNB nicht mehr stabil versorgen konnte (die Spannung brach ein, sobald der LNB versucht hat, wirklich Strom zu ziehen). Das passt schon durchaus ins Bild. Insofern: Gratulation, das gefunden zu haben, bevor noch viel mehr Arbeit bzw Geld in den Ausschluss anderer Fehlermöglichkeiten fließt ;)


    HTH,
    Andre.

    Quote

    Originally posted by valbuz
    Kann mir nicht vorstellen, dass ein Sender, aus dieser grossen Auswahl, anders gestrickt sein sollte.....zumal es nur ein Regionaler ist.


    Gerade deswegen kann das sein - die encoden vielleicht selbst und haben u.U. was verstellt, wodurch das Resultat beim Video Elementary Stream nicht mehr 100% ETSI-konformes DVB ist. Sieht auf den ersten Blick zwar nicht so aus (High Profile @ Level 4.0 sollte passen), aber was behauptet wird und was dann wirklich drin steckt können auch zwei verschiedene Dinge sein. Müsste jemand mit viel Geduld und den richtigen Tools mal im Detail analysieren und gegen die Specs halten...


    BTW, Gemeinde-TV in HD - vornehm geht die Welt zu Grunde ;)


    HTH anyway,
    Andre.

    Quote

    Originally posted by Hein Holz
    Hast Du bei 73 MHz einen ungestörten Empfang? 29 dB sind schon etwas knapp für QAM256.


    Fiel bisher nicht auf, da treibt sich nur Sky rum. Hab da aber jetzt mal hingezappt. Das Ergebnis ist interessant: Obwohl scan das hier

    Code
    Freq=73, SNR=3009, Status=1f, SR=6945, FEC=0, Mod=5

    ausspuckt, habe ich - sobald ich dort getuned bin - eine gute SNR um 35dB (siehe Screenshot). Kann sein, dass Du den beim scannen nicht richtig triffst oder der Tuner dort länger braucht. Ich hatte erst angenommen, der wäre hier stärker durch Einstreu gestört - die Zeiten von FM aus dem OIRT-Raum (die sich AFAIR dort unten rumtrieben) sollten aber eigentlich vorbei sein, seit sich meine unmittelbaren südlichen und östlichen Nachbarn auch in der EU tummeln (dachte ich)...


    Quote

    Für QAM64 reichen 24 dB. Deswegen werden diese Kanäle von KDG auch nur mit 1/4 der Leistung eingespeist. Es ist daher kein Fehler, dass die etwas niedriger erscheinen.
    Bei so wenigen Kanälen ist die Summenspannung erheblich niedriger. Es entstehen weniger Mischprodukte.


    Würde bei 122MHz passen, bei 434MHz aber eigentlich nicht. Egal, ist "Premium HD" - genau so don't care wie Sky ;)


    Thanks & HTH,
    Andre.

    Files

    • d73.jpg

      (23.61 kB, downloaded 239 times, last: )
    Quote

    Originally posted by Hein Holz


    Ich hab oben eine neue Version hoch geladen, wo jetzt auch die 73 MHz geprüft werden sollten.


    Spitze, funktioniert. Ich hab mal einen Screenshot angehängt, weil Du das ja selbst gar nicht testen kannst.


    Was den Tuner angeht: Ich hatte in der Anfangsphase meiner DM7020HD hier auch den Eindruck, dass der Tuner zickig ist, speziell weil er im Loop-Betrieb (der bei DVB-C ja völlig alltäglich ist) immer mal wieder Aussetzer produzierte. Wurde irgendwann besser, aber ob das Software war oder primär daran lag, dass ich hier die Verkabelung angepasst habe (Splitter vor der Box, Kabel mit Schirmmaß 110dB oder mehr, Verlegung ohne Gefahr der Selbsteinstreu), lässt sich kaum noch nachvollziehen. Der HD-Tuner in meinem Samsung-TV ist zickiger ;)


    Thanks,
    Andre.

    Files

    • cscan.jpg

      (97.67 kB, downloaded 816 times, last: )
    Quote

    Originally posted by Hein Holz
    Ich habe das hier benutzt, um das ipk-Paket zu bauen:

    Code
    # ipkg-build -- construct a .ipk from a directory
    # Carl Worth <cworth@east.isi.edu>
    # based on a script by Steve Redler IV, steve@sr-tech.com 5-21-2001


    Wo die Fehlermeldung her kommt, weiß ich gar nicht. Es werden alle Dateien richtig installiert.


    Ich hab mal geguckt, Dein control-File sieht so aus:


    Da ist irgendwie ein Space hinter das finale Newline geraten, das eigentlich davor (oder ganz weg) gehört. Ich kenn ipkg-build nicht (mach sowas so selten, dass es mir händisch mit $EDITOR, tar, gzip und ar reicht).


    Quote

    Wenn bei Dir 73 MHz noch benutzt wird, hast Du ein "nicht ausgebautes" Kabelnetz.


    Yep, das ist mir schmerzlich bewusst - halbe Leistung zum vollen Preis. KDG saugt.


    Quote

    Bei mir ist da nichts. Ich könnte das einbauen. Ist aber etwas umständlich, weil es nicht auf dem 8 MHz-Kanalraster liegt wie alle anderen Kanäle und ich müsste die Skala nach unten erweitern.


    Das ist das Problem mit einem Programm, das irgendwas misst - es werden immer Leute kommen, bei denen etwas anders ist als bei Dir. Messen ist der Vorgang, wo wir hart mit der objektiven Realität zusammenstoßen, und die hält sich (außer an Naturgesetze) nicht an lokale Standards ;)


    Andernorts auf der Welt gibt es sogar abweichende Kanalraster. Und wenn irgendwo was schräg ist (kleine lokale BK-Anbieter oder winzige Kopfstationen können allen möglichen Unsinn machen, den sich die überregionalen wegen der Supportkosten früher oder später zu verkneifen lernen), dann ist es natürlich clever, wenn mir das Messprogramm das auch sagt. Leider kriegst Du zwar SNR aber keinen Pegel, und falls Du AGC kriegen solltest stellt sich immer noch die Frage, ob man daraus wirklich (mit viel Vorsicht) auf den Pegel schließen könnte. Müsste man mal visualisiert sehen...


    Ich will Dich in keinster Weise zu Arbeit verdonnern, die Du nicht machen willst. Ich sag nur, was cool wäre - ein voller Überblick über alles, was der Tuner demoduliert kriegt, egal wo das rumfliegt und wie schräg das neben den offiziellen Standards sitzt. Dass der Scan da länglicher wird, liegt auf der Hand ;)
    Wenn Du hier mal vierstellige Downloads hast, denk noch mal drüber nach. Momentan würd ich da auch nix supporten, das vielleicht niemand braucht.


    Quote

    Ich habe das Plugin geschrieben, weil bei mir auch nicht alle Kabelkanäle einwandfrei empfangen werden. Das liegt aber wohl an dem minderwertigen Tuner CXD1981. Mein Fernseher empfängt z.B. die Frequenz 378 MHz einwandfrei, die Dreambox leider gar nicht. Da wollte ich mir mal einen Überblick verschaffen.


    378MHz ist bei mir relativ unauffällig, die zwei deutlichen Ausreißer sind bei 122 und 434MHz. Hab das noch nicht analysiert, aber wahrscheinlich liegen da lokale DVB-T-Kanäle drüber, die einstreuen und die SNR drücken. Ich brauch dringend mal einen richtigen Spectrum Analyzer, leider liegt eine andere Frequenz, die für mich von höchstem Interesse wäre, genau im Loch von Elonics E4000, so dass osmocomSDR/rtl-sdr nicht wirklich in Frage kommen... (wird aber sehr OffTopic)


    HTH & Thanks,
    Andre.

    Quote

    Originally posted by hNt`
    ich hab seit einiger Zeit das Problem, dass manchmal, wenn ich eine Aufnahme auf mein NAS verschieben will, der Fehler "Cannot allocate memory" auftaucht. Nach einem GUI-Neustart funktioniert es dann wieder. So richtig steige ich nicht dahinter, warum der Fehler seit einiger Zeit auftaucht und was für ein "memory" gemeint ist.


    RAM. Der ist auf der 8000er ja doch eher knapp (im Vergleich zur 7020HD und den neuen V2-Boxen), d.h. die ganz gewöhnliche zunehmende Verfettung aller Software kommt inzwischen auch dort an, selbst wenn man sonst nichts extrem RAM-fressendes treibt (Klassiker ist immer noch EPG von mehreren Sats, womöglich noch aus dem Internet dazu Geladener).


    Quote

    Hatte erst gedacht, dass es was mit dem Skin zu tun haben könnte, weil mir der Fehler direkt nach einem Update des holo Skins aufgefallen ist. Den Gedanken hab ich aber wieder verworfen, weil es ja mal geht und mal nicht.


    Die holo-Skins sind jetzt nicht wirklich die Ressourcensäue (da gibt's ganz andere). Aber natürlich kosten auch hochwertig gestaltete Skins RAM, der irgendwo anders fehlen kann. Geht es mit dem Default HD Skin zuverlässig weg?


    Quote

    Jemand Erfahrung damit oder einen Gedanken dazu?


    Hast Du schon mal über Swap nachgedacht?


    HTH,
    Andre.

    Quote

    Originally posted by Hein Holz
    ich weiß nicht, ob überhaupt jemand dieses Plugin gebrauchen kann...


    Aber klar doch! Schon mal schön zu sehen, welche zwei Multiplexe hier deutlich in der SNR abfallen. Und man sieht auch auf einen Blick, ob man KDG ausgebaut ist oder nicht...


    Bei der nächsten Kabel-Störung Upstream wird es auch enorm helfen, das Drama auf einen Schlag zu visualisieren. Coole Idee - Danke dafür.


    Quote

    Verbesserungsvorschläge nehme ich gerne entgegen. Viel Spaß damit!


    Zwei Sachen:

    Code
    root@dm7020hd:/media/usb/package# opkg install enigma2-plugin-extensions-cablescan_0.01_mips32el.ipk
    Installing enigma2-plugin-extensions-cablescan (0.01) to root...
    Configuring enigma2-plugin-extensions-cablescan.
    Collected errors:
    * parse_from_stream_nomalloc: Missing new line character at end of file!
    * parse_from_stream_nomalloc: Missing new line character at end of file!

    Ich vermute, da sind Metafiles im Package mit mcedit oder sowas bearbeitet worden? Fehlendes Final Newline ist ein Klassiker ;)


    Und dann vermisse ich hier D73 (auf 73MHz), wo KDG doch wirklich noch einen DVB-C-Multiplex untergebracht hat (statt mal endlich die Wüste oberhalb 480MHz zu erschließen, von der Analog-Wüste ganz zu schweigen). Wenn ich das richtig parse:

    könnte der CXD1981 von 50.5MHz bis 900MHz scannen. Ignorierst Du momentan alles außerhalb des Fensters 114MHz-858MHz? Ich würde vorschlagen, mitzunehmen was mitzunehmen ist - könnte interessant sein ;)


    Thanks again & HTH,
    Andre.

    Quote

    Originally posted by mr_0815
    Dann muss es doch die 8000 werden, denn ich möchte nicht noch einen DVD player herumstehen haben.


    Kann ich mich nur meinen Vorrednern anschließen: Du wirst Dir schnell wünschen, Du hättest den zusätzlichen Player. Zumal der dann ein BD-Player sein kann, der nicht nur olle DVDs sondern auch aktuelle Scheiben mit HD-Inhalten anstandslos wiedergeben wird. Was wirklich zählt ist viel RAM, viel Flash und die größte PVR-geeignete HDD, deren aktuelles Preis-Leistungs-Verhältnis noch vernünftig ausfällt (momentan wahrscheinlich 4TB WD Red).


    HTH,
    Andre.

    Quote

    Originally posted by MMS


    wollte gerade paar auf der DM8000 (OE2.0) aufgenommenen Filme auf die DM800se kopieren. Direkt per FTP über den TotalCommander scheint nicht zu gehen .. ?


    Ich kenn TC jetzt nicht, aber wenn der das wirklich könnte (dual control connection zu zwei FTP-Servern und direktes File-Bounce via PASV) dann rennt er wohl in einen Bug (oder ein überreagierendes Sicherheitsfeature) in vsftpd:


    Mit ftp -vd sieht der letzte Teil so aus:

    Code
    ftp> proxy get "20140505 0140 - ZDF HD - Frag den Lesch.ts"
    local: 20140505 0140 - ZDF HD - Frag den Lesch.ts remote: 20140505 0140 - ZDF HD - Frag den Lesch.ts
    ---> TYPE I
    dm800.lan:200 Switching to Binary mode.
    ---> PASV
    dm800.lan:227 Entering Passive Mode (192,168,1,40,99,54)
    ---> TYPE I
    dm7020hd.lan:200 Switching to Binary mode.
    ---> PORT 192,168,1,40,99,54
    dm7020hd.lan:500 Illegal PORT command.


    Da nimmt der vsftpd auf der dm7020hd also ein PORT command nicht für voll, weil die IP da drin die der dm800 ist und nicht die des verbundenen Clients. Und wieder geht ein hilfreiches Feature, das seit Jahrzehnten funktioniert hat, den Bach runter...


    Meh,
    Andre.

    Quote

    Originally posted by netman
    Das kann man doch einfach über den Feed laden:


    Nicht bei jedem Image (sonst hätte ich mir das Bauen natürlich gespart ;)
    Bei DMM allerdings schon, und das führt dann auch zu dem "Problem": Mein Build hat nicht den Hash, den der von DMM hat, aber exakt die selbe Version. Da weigert sich opkg legitim, das zu installieren, könnte ja kompromittiert sein.

    Quote

    opkg update && opkg install tcpdump


    Yep, sollte dann reichen. Ich detache dann hier mal das Attachment, da sich das jeder auch aktuell bei DMM ziehen kann, selbst wenn er nicht ohnehin an deren Feed hängt.


    Sorry für den Trubel,
    Andre.