Willkommen! Melden Sie sich an oder registrieren Sie sich.

Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.

Anmelden - oder - Benutzerkonto erstellen

Beiträge von WilliamG

    Auch ich wünsche Euch allen ein gesegnetes und geruhsames Weihnachtsfest und einen guten Rutsch ins' neue Jahr.
    Macht es richtig und nutzt diese Zeit für die Familie und zur bewussten Entschleunigung des Alltags!


    Endlich Urlaub :)

    Ah, in der Keyids war das. Genau.
    Ich habe rcused an der 7020HD gesetzt, weil ich noch die alte RC benutze und teilweise andere Keyids benutzt werden.
    Daher kann ich das Problem mit der Webremote wohl auch nicht nachvollziehen.


    Hilft das hier?


    P.S.: Ganz ohne Box, auf der man schnell mal etwas remote nachschauen kann, ist es wirklich schwierig zu supporten. Respekt an m0rphU, der das schon eine ganze Weile so machen muss :blinz:
    Ich bin zum Glück nur noch heute boxenlos :)

    Manuell config.misc.rcused= gesetzt oder eventuell eine veränderte Keymap im Einsatz?
    Generell sollten sich die Mappings für die verschiedenen RCs in der Keymap wiederfinden. Habe nur gerade keine Box hier um nachzuschauen.


    Vielleicht ist es aber auch wirklich ein Bug.
    Irgendwie habe ich im Hinterkopf, dass es vor einer Weile ein ähnliches Thema im Dreamboard oder in #enigma2 gab.. finde gerade aber auf die Schnelle nichts in Board oder Logs.

    Wenn systemrelevante Daten in der korrupten Node liegen, dann muss tatsächlich neu geflasht werden.
    Ich würde auch gar nicht groß weiter debuggen..


    Sollte kein sauberes Backup vorhanden sein und noch einzelne Files via FTP gesichert werden, beim Kopiervorgang /var/log/messages tailen und nach Lesefehlern Ausschau halten.
    Wenn diese auftreten, dann besteht eine hohe Wahrscheinlichkeit, dass die aktuell gelesene Datei korrupt ist und nicht verwendet werden sollte.

    sparks hat Recht.
    Ich überfliege die "gutemine Threads" zwar seit Wochen nur noch, weil mir die ganze Situation um den 2-Fronten-Krieg auf den Geist geht.
    Aber zum Streiten bedarf es immer mindestens zweier Parteien und letztendlich sind alle, die sich über die Lage/Reaktionen/etc. beschweren, auch bedingt daran mit schuld.


    Wenn es hier im Thread auch wieder aus dem Ruder läuft, können wir durchaus auch mal einen anderen Moderationsstil an den Tag legen und themenfremde und/oder streitsüchtige Beiträge entsprechend verschieben.
    Wobei wir doch eigentlich alle erwachsen sind und das keiner wirklich will, oder?

    Zeig mir doch bitte mal Deine nachvollziehbaren Messungen was die Leistungsunterschiede beim Decoding von ALAC und FLAC angeht, bevor Du mich Lügen strafst.
    Denn dass ALAC Decoding in der Regel CPU intensiver als FLAC Decoding ist, ist eine allgemein bekannte und nachweisbare Tatsache.
    Klar.. auf einem halbwegs modernen PC mit all-purpose CPU fällt das kaum ins Gewicht. Auf embedded Systemen kann das hingegen durchaus das Zünglein an der Waage sein.
    Misinformationen bringen Dich kein Stück näher an eine funktionierende Implementierung. Insbesondere wenn diese dann genau an einem der zu Beginn aufgebrachten Punkten scheitern würde.


    Deine Behauptungen zur Codecverbreitung von FLAC vs. ALAC halte ich nicht nur für fragwürdig, sondern für falsch.
    Sie mag vielleicht für die quietschbunte Apple Welt stimmen, für die reale Welt jedoch nicht.
    Geht es nur um mobile Devices, gilt es u.a. auch die native FLAC Unterstützung ab Android 3.x zu bedenken.


    Ich bezweifle auch, dass Du Aussagen darüber treffen kannst, was die Mehrheit an "Audiophilen" verwendet und was nicht.
    ReplayGain hat nichts mit Wiedergabequalität, sondern mit Convenience zu tun. Und ist bis heute imho immer noch der beste Ansatz um eine einheitliche Wiedergabelautstärke und Clippingverhinderung zu ermöglichen.


    Auch kenne ich Dein Archivierungskonzept nicht, aber fehlendes Errorhandling im Codec selbst halte ich für einen großen Schwachpunkt von ALAC.
    Ich würde Dir empfehlen, Dich mal mit bit rot bzw. data decay auseinanderzusetzen.
    Weiterhin lege ich Dir die Lektüre des Hydrogenaudio Wikis nahe, wenn Du dich fundiert mit den Unterschieden zwischen den verschiedenen lossless Encodern beschäftigen möchtest.



    Die wenigsten AVRs werden einen ALAC Bitstream dekodieren können (falls es überhaupt spezifizierte Übertragungswege bzw. Enkapsulationsmethoden für so etwas gibt).
    Es muss also gestreamt oder dekodiert werden.


    Wenn es Dir um hochwertige Audiowiedergabe geht, brauchen wir eigentlich gar nicht weiter zu diskutieren.
    Denn die Dreambox ist dafür nicht geeignet. Sie bietet - wie die allermeisten Consumer Multimediageräte - keine bit-genaue Wiedergabe.
    Diese bekommst Du beispielsweise mit einer hochwertigen und richtig konfigurierten Wiedergabekette mit foobar2000 hin.

    Ja, es gibt den DVB-IPTV Standard.
    Den nutzt aber afaik so gut wie niemand und laut Wikipedia unterstützt ihn kein TV.


    Man muss bei dem ganzen Marketingsprech auch zwischen IPTV im Allgemeinen und SAT-IP im Besonderen unterscheiden.
    Insbesondere der Begriff IPTV ist ja sehr lose definiert.


    Das Partnerbox Plugin vom Doc macht, je nach Definition, auch SAT-IP bzw. IPTV. Nur eben nicht mit unabhängiger standalone Hardware.

    Bei uns liegt dFlash gar nicht auf dem Feed.
    Du kannst im OPKG für spezifische Pakete den HOLD Flag setzen, dann werden diese bei Updates nicht berücksichtigt. Mit allen Vor- und Nachteilen.
    Einige der Konsequenzen hat gutemine bereits gelistet.


    Wie das geht findest Du über die Boardsuche oder die Suchmaschine Deiner Wahl.

    Vom Prinzip her konnte die Dreambox schon "SAT-IP" bevor der Begriff von den Medien/Marketing überhaupt geprägt wurde.
    Welche Specs ein Stream einhalten muss, damit er mit einem Panasonic TV konform geht, weiß ich nicht.
    Das Problem ist, dass es höchstwahrscheinlich mal wieder keine einheitlichen Standards gibt, an die sich alle Hersteller halten.


    Eine kurze Googlesuche hat ergeben, dass bei SAT-IP Geräten oft DLNA bzw. UPnP zur Verteilung der Streams an die Clients genutzt wird.
    Die DLNA Implementierung ist auf der Dreambox noch nicht weit fortgeschritten und funktioniert nicht universell, da für volle Kompatibilität meist für jedes Endgerät eigene Workarounds notwendig sind.
    Am besten einfach mal mit der eigenen Hardware und dem Demo Plugin testen.
    Letztendlich fehlt es an einem engagierten Entwickler mit viel Freizeit, der einen entsprechend großen Gerätepark zur Verfügung hat und das Projekt aus Eigeninteresse voran treibt.

    Das Plugin ist open source. Es steht Dir frei entsprechende Anpassungen vorzunehmen und hier zu posten.
    Bei Gefallen werden diese dann auch gegebenenfalls übernommen.


    Über Sinn und Unsinn darüber, auf einen ehemals proprietären und nur von Apple forcierten Codec ohne Errorhandling und richtigen ReplayGain Support zur Langzeitarchivierung zu setzen, lasse ich mich an dieser Stelle lieber nicht aus.
    ALAC braucht mehr CPU Leistung beim Decoding als FLAC. Ob die Dreambox ein Softwaredecoding (gerade bei hohen Auflösungen) von der Leistung her schafft, gilt es zu testen.
    Generell ist ALAC Support machbar. Es muss sich nur jemand finden, der Interesse daran hat und es implementiert.

    Wenn Du die nötigen stand-alone Pakete und eventuelle Anpassungen/Eigenheiten hier postest, dann könnten wir uns das mal anschauen.
    Vom Team nutzt afaik keiner ein VPN auf der Dream und mit reinen Trockenübungen ist das so eine Sache.
    Ich hätte beispielsweise gar keinen entfernten (nicht Loopback) VPN Server, auf dem ich mit einem nicht authorisierten Gerät testen könnte.

    mdshd
    Sorry, aber an Deiner Unfähigkeit ist weder die Dreambox, noch das Merlin Image schuld.
    Ich habe bei ettlichen Boxen (inklusive derer, die ich für DAUs remote betreue) höchstens alle paar Monate mal einen Greenscreen. Und der ist in 95% der Fälle selbstverschuldet.
    Wenn bei den Anderen alles so viel schöner, besser und toller ist, was hält Dich dann noch hier bzw. bei DMM?


    P.S.: Eigentlich gibt es von mir ja kein Trollfutter, aber es ist gerade so ruhig hier.. :D

    Jetzt kapiere ich erst was Du überhaupt machen willst.
    Das kann funktionieren, muss aber nicht. Kommt darauf an, ob das Dateisystem zum Zeitpunkt der Stickerstellung schon einen Schlag weg hatte.
    Einfach probieren und berichten. Zu verlieren hast Du ja nichts.


    Ich selbst würde aber nicht lange herumdoktern, sondern schnell neu flashen und einrichten.
    Und dann direkt und in regelmäßigen Abständen automatisiert Backups erstellen..


    Außerdem würde ich über eine RMA bei DMM nachdenken, wenn grundlos immer wieder das UBIFS im Flash wegstirbt.
    Natürlich nur, wenn man eigenes Verschulden (Hard Resets, etc.) ausschließen kann.



    P.S.: Das ist doch alles völlig imageunabhängig.
    Und Oldboke hat insofern Recht, dass Du wahrscheinlich dort, wo viele Leute bestimmte Tools nutzen und deren Devs unterwegs sind, besseren Support zu diesen bekommen wirst.



    €dit: Eben erst Deinen Edit und letzten Beitrag gesehen.
    Wäre das vorher schon da gestanden, hätte ich gar nichts geschrieben.
    Auch wir vom Team haben sonntags besseres zu tun als uns anpatzen zu lassen.


    Und wenn Deine Probleme nicht an der Hardware liegen, sitzt der Fehler mit 90%iger Wahrscheinlichkeit an der in marthoms Signatur beschriebenen Stelle.
    Denn reproduzierbar oder allgemeingültig sind sie - mit der aktuellen Informationslage - auf jeden Fall nicht.

    Nein, wenn das Dateisystem hinüber ist, ist es zu spät um Backups zu erstellen.
    Diese macht man bestenfalls während noch alles funktioniert.


    Wenn Dir immer wieder bei gehäuften R/W Operationen im Flash (z.B. Updates) das UBIFS wegstirbt, könnte das auch auf ein Hardwareproblem hindeuten.
    Aber ohne ein aussagekräftiges Log ist das schwer zu sagen.

    Der 1. Googlehit zu dem Fehler würde auf korrupte PYC Dateien hindeuten.
    Jetzt könntest Du explizit die betroffenen Dateien (oder in der Shell per Platzhalter gleich alle) löschen. Diese sollten dann beim nächsten Boot - sofern sie im Source vorliegen - neu kompiliert werden.
    Aber ich würde eher auf ein kaputtes Dateisystem als zugrunde liegende Problemursache tippen. Da wäre diese Vorgehensweise dann höchstens Symptombekämpfung.


    Sind irgendwelche Auffälligkeiten im Syslog, Kernellog bzw. Ringpuffer zu erkennen?


    Da ich von hier aus nicht an das komplette Crashlog herankomme: hast Du zwischenzeitlich auch schon den Crashloop mit init 4 gestoppt und in den /etc/enigma2/settings auf den default Skin umgestellt?
    Nicht, dass es doch am Skin liegt und das aus dem Crashlogausschnitt nicht deutlich wird.
    Wobei ohnehin auf den default Skin revertet werden würde, wenn Du den Ordner des aktuell verwendeten Skin gelöscht hast.