Beiträge von tmbinc

    Hi,


    sorry, this is probably a bug in the demux microcode we are using. We already tried working around that issue, but that won't work in all cases.


    We will try finding an ultimate solution here, but I wouldn't count on it. Sorry.


    It would probably help if we can understand when this corruption happens. My guess is that the demux microcode detects some "condition" and somehow handles that incorrectly. If we knew what exactly triggers that, it would possibly help in understanding the reason for this misbehaviour.


    Fangen wie damit mal an:


    1. Wenn enigma1 etwas aufnimmt, dann fehlt dort keine PAT, PMT oder Audio-PID. Bin mir über den Zustand des V1-Supports in enigma2 nicht ganz im klaren, aber ausser der einschränkung, dass nur eine Aufnahme zur Zeit möglich ist, sollte es da keine Probleme geben. Wenn doch, ist das ein enigma2-Problem, was dort gefixt werden kann.


    2. Ja, weil enigma2-streamproxy kein API v1 kann. Das ist kein Treiberbug.


    3. Geh ich gleich nochmal drauf ein.


    4. Die Tasten werden nicht als Inputdevice weitergegeben. Man könnte eRCDeviceDreamboxButton in enigma2 wiederbeleben. Das wäre allerdings ernsthaft eine Sache, die man im Treiber mal einbauen könnte.


    5. Enigma1 kanns doch aber auch. Die gstreamer-plugins sind dvb v3 only. Die müsste man anpassen.


    Dann, Hein Holz:

    Zitat


    1. Fernbedienung
    2. Aufnahme


    1. Ich hab gerade keine 7020 da, was ist denn falsch? Kommen keine Repeats, sondern gleich ein release? Aber das ist etwas, was man durchaus im Treiber fixen könnte, ja.


    2. Der Pallas hat drei demuxe, der Vulcan nur einen. Dafür wird im Vulcan-Treiber einiges per Software geradegebogen, was die Hardware nicht kann. Kannst du ermitteln, was in der Aufnahme genau fehlt? Man z.b. nicht demux0 zum Aufnehmen nehmen (was auf der 600PVR natürlich funktioniern muss, da diese nur einen hat), weil die Streams nicht wie bei der 600er in Software auseinandergenommen werden, und die Hardware einen Stream nicht gleichzeitig zum Videodekoder und in den Speicher schicken kann.

    Es gibt recht beeindruckende Images von enigma2 z.b. auf der DM600PVR.


    Die 7020 hat eine sehr gut funktionierende GUI namens enigma1. Mit diesem wurde sie verkauft und beworben. Wenn enigma2 auf diese Box portiert wird, dann wird das immer ein inoffizielles Projekt werden, egal wer das nun tut (sei es jemand von uns oder aus der Community). Wir werden es bestimmt nicht torpedieren, wenn für alte Hardware von uns neue Anwendungszwecke gefunden werden. Nein, wir haben es nicht SO nötig neue Boxen zu verkaufen.


    Aber: Irgendwann hat das Grenzen. Der CI-Treiber z.b. müsste komplett neu geschrieben werden, weil da sehr große konzeptionelle Unterschiede bestehen, wenn er aus Usersapce-sicht kompatibel werden soll. Das heisst aber nicht, dass jemand darauf angewiesen wäre, das im Treiber zu machen - enigma1 kann es ja auch, das beweist doch, dass die aktuellen Treiber es können. Jeder, der programmieren kann, kann doch enigma2 entsprechend anpassen, um mit den alten treibern zu funktionieren. Ja, das ist Aufwand. Aber "die Treiber können es nicht" ist doch nur eine Ausrede, die Funktionalität ist doch da.


    Bestimmte Dinge wie "Videos abspielen" fangen an kompliziert zu werden, sobald da irgendwelche dekoderspezifischen Kleinigkeiten dazwischenkommen. Das ist aber auch wieder hauptsächlich eine Userspace-Sache (schaut euch z.b. mal an, was wir da aktuell für die DM800 machen (müssen) - das ist keine Magie, nur nerviger Code, und hat mit den Treibern nichts zu tun). Da kann man nicht erwarten, dass das "mal eben" geht.


    Aber: Die DM7025 war als Enigma2-Box geplant, die 7020 nicht. Das ist aber doch jedem klar gewesen, oder?


    Alle "kleineren" Dinge haben wir doch bereits in den Treibern zurückportiert (z.b. die /proc/stb-Sachen). Aber es hat halt irgendwo Grenzen - nämlich dann, wenn es ein beachtlicher Entwicklungsaufwand wird, der nur für ein inoffizielles Hobbyprojekt interessant ist. Ich glaube nicht, dass enigma2 auf der 7020 jemals einen Stand erreichen wird, der mit der 7025 konkurrieren kann - ansonsten hätten wir doch schon lange enigma2 auf die 7020 offiziell portiert - es wäre auch für uns wesentlich weniger aufwand, wenn alle Boxen die gleiche Software hätten. Das heisst aber nicht, dass da nicht durchaus was "brauchbares" bei rauskommen kann. Nur zwischen "brauchbar" und "offiziell" liegt noch ein großer Unterschied.


    Um das ganze mal auf die technische Ebene zurückzuholen: Macht doch mal eine konkrete Liste, was aktuelle 7020 Treiber nicht können. Vielleicht lässt sich für einzelne Dinge ja ein Lösungsweg finden. Aber ihr müsst auch damit leben, dass die 7025 einfach neuere Hardware ist. Ansonsten hätten wir ja den Pallas beibehalten. Auch wir haben keinen Spaß dran, grundlos die Hardware zu verändern, nur um dann hinterherzuprogrammieren.

    Hm, mal wieder gabs "keine Änderungen die damit was zu tun haben könnten" - wie immer also :winking_face:


    Ich hab nochmal neue treiber gebaut (20080319), einzige änderung ist, dass die WSS zeile nicht mehr rausgeschnitten wird.


    Was ausserdem verändert wurde, ist das verhalten von WSS (also diesmal die *eingefügte* Zeile) und Slowblank bei Panscan und Letterbox. Ich denke nicht, dass es daran liegt, aber versucht nochmal bitte (falls der treiber nichts bringt):


    echo "off" > /proc/stb/denc/0/wss


    Danke fürs testen!

    dvbsnoop ist auf der box vorinstalliert, und lässt sich per telnet starten. mit "dvbsnoop -spiderpid 0 > /tmp/datei" wird die ausgabe dann nach /tmp/datei geschrieben.


    Wie gesagt, ich hätte alternativ auch Interesse an der Aufnahme.


    Das "garkein Ton" hat wohl nichts mit dem im Treiber vom 3.3. behobenen Fehler zu tun, insbesondere, da der Ton ja auch nicht aufgenommen wird.

    Ohje, naja, in nen paar tagen wirds bestimmt wieder gehen :winking_face: Ich werd mir mal eine Aufnahme anschauen, und schauen, was da mal wieder anders ist.


    Gazelle: versteh ich das richtig, dass der Ton auch nicht da ist, wenn man das File z.b. mit VLC abspielt?


    Wenn ja, kann mir jemand mal das ergebnis von "dvbsnoop -spiderpid 0" (auf dem transponder) zuschicken?

    komisch, komisch, das mit RTL. Hat jemand ne Aufnahme, als es gerade nicht ging?


    MickeyM: was war die neuste treiberversion, wo das Problem noch nicht auftrat?


    (Im Angebot stehen: 20070420, 20070826, 20070924, 20071001, 20071007, 20071029, 20071106, 20071107, 20071109, 20071121, 20071123, 20071126, 20080229, 20080303 - einfach in der url unten das Datum ändern)


    Felix

    Also, das "Jitter"-Problem hatten wir schonmal, wurde ausreichend erklärt. Das betrifft dann aber alle Sender, AC3 und Stereo, und halt nicht alle AV-Receiver. Und ja, wir sind immernoch dabei, einen Fix zu entwickeln. Neues erzähl ich, sobald es neues gibt. Und um es nochmal in aller Deutlichkeit zu sagen: Der SPDIF-Ausgang (am Chip) entspricht den Spezifikationen und wurde von Dolby auch so zertifiziert. Das hilft euch nicht weiter, das weiss ich auch, sollte aber nochmal klarstellen, dass es nicht ein Problem der Dreambox alleine ist.


    Daneben gibts aber das "RTL-AC3-DVB-C"-Problem. Wer *das* hat (und nur das), möge sich bitte mal bei melden (tmbinc@elitedvb.net).

    also der bluescreen stammt nicht von den treibern, sondern ist irgendein bug in enigma2 (hab ihn mir noch nicht genauer angeschaut). In sofern war das wohl zufall.

    Freut mich, dass das Problem jetzt wohl behoben ist! :smiling_face:


    Zur technischen erläuterung:


    sowohl das LCD als auch die CF/IDE-Umschaltung hängen an einem GPIO port. Im kernel findet sich folgendes:


    Im LCD treiber gibts dann grob gesehen

    Code
    static inline void setCLK(int clk)
    {
      if (value)
        SETREG_REGMM32(GPIOA_DATA, GETREG_REGMM32(GPIOA_DATA) | LCD_CLK);
      else
        SETREG_REGMM32(GPIOA_DATA, GETREG_REGMM32(GPIOA_DATA) & ~LCD_CLK);
    }

    dreambox_set_ide_bus wird durchaus im Interrupt aufgerufen (nämlich wenn z.b. der letzte festplatten-Transfer fertig ist, und der nächste Transfer zur CF-Karte geht).


    Der LCD-Treiber wird ausnahmslos aus dem Userspace aufgerufen (der write-Handler vom LCD-Device).


    setCLK liest den alten register-wert, ORt bzw. ANDed das CLK-bit rein/raus, und schreibt es dann zurück. Nun kann unter (wohl nicht allzu seltenen umständen) es passieren, dass das register gelesen wird, das bit geändert wird - und dann aber ein CF-interrupt passiert, wo der bus umgeschaltet wird. Dort wird also das register (welches ja noch nicht im LCD-Treiber geschrieben wurde) gelesen, das CF-bit verändert, geschrieben, und dann aus dem interrupt zurückgekehrt, wo der lcd treiber seine arbeit fortsetzt, und den vorher berechneten register-inhalt schreibt - tja, leider geht dann die änderung aus dem IDE-treiber verloren.


    Ein paar dringend benötigte spinlocks (bzw. interrupt-sperren, mehr bleibt auf UP davon ja nicht übrig) haben das problem behoben.

    nun, seit 1.5 ist ja root=boot, weil wir uns nicht mit einem initramfs etc. rumschlagen wollten (was ja auch am ziel vorbei geht). ein "realroot" aus der kernel cmdline zu holen wäre natürlich drin. notfalls kann auch alles in eine partition dann, wobei das delta in nem ordentlichen dateisystem bleiben sollte (und nicht vfat). gegen ein rootdir hätte ich dann auch nichts einzuwenden.


    was ich dann nur nicht verstehe:


    eine 16GB CF karte kostet knapp hundert euro. Wieso will da irgendjemand noch platz (auf kosten des komforts) sparen?! das squashfs+unions ist doch ne notlösung, weil jffs2 durch die geringe pagegröße schlecht packt...