Beiträge von jasminj

    Ah, jetzt weiß ich wofür dieser Idle-Buffer gut ist - er beschäftigt das CAM obwohl es eigentlich gar nichts zu tun gibt.

    Nein das ist nicht der Grund.
    Das liegt am Ngene Chip der eigentlich für Audio gedacht ist und immer etwas erwartet, weil bei Audio ist das einfach so. Man hat das dann mit den leeren TS Paketen im Treiber gebastelt.


    Den Offset in tsin_exchange() einfach zu überspringen wird auch nicht gut funktionieren da dann zwangsläufig das unvollständige (<188 byte) TS-Paket am Ende nicht mehr in den Tsin Ringbuffer geschrieben wird. Man verliert also bei jedem exchange 1 TS-Paket.

    Ein Paket verlieren geht gar nicht, dann ist der Stream kaputt!

    Wenn man ohne zusätzlichen Buffer auskommen will, dann muss man eben den Rest (immer <188 Bytes) in ein kurzes Array umkopieren und beim nächsten Pakerl dann als erstes in den Output Buffer schreiben. Und man müsste immer überprüfen, ob der Offset noch passt. Das kann man aber recht billig lösen und macht das ddci2 Plugin auch.


    LG,
    Jasmin

    Nein das passt so, weil "ptr" ein "u32 *" ist und somit ein += 1 in wirklichkeit den Pointer um 4 Byte verschiebt.

    Deshalb muss man eben "+= (188/4)" schreiben, wenn man den Pointer um 188 Bytes verschieben möchte.

    Die Length ist aber die Länge in Bytes und deshalb gehört dort ein "+= 188".


    Einer der Pitfalls bei der Pointer Arithmetik in C ;)


    LG,

    Jasmin

    Ich kann gerne ein Droppen dieser Pakete beim Lesen vom DVB-Device einbauen.

    Hat eigentlich jemand getestet ob die NULL Pakete aus dem DVR Device gekommen sind oder vom CI/SEC Device, also nach dem CAM?


    Aber anscheinend haben wir inzwischen kein System mehr, auf dem dieses Problem auftritt und mit dem wir es testen könnten.

    Na ja, Daniel bekommt eine ngene Karte, aber ich weiß nicht ob er Zeit hat sich das anzuschauen.
    Wichtig wäre eben zu wissen woher die NULL Pakete kommen, weil im TS Stream vom Satelliten sind die nicht drinnen.

    Und wenn du den Filter nur nach dem DVR Device lesen einbaust, es wird aber vom CI/SEC Device produziert, dann haben wir die Pakete immer noch. Man müsste also auch die Pakete die aus Decrypt heraus purzeln auf NULL Pakete untersuchen.


    LG,
    Jasmin

    Na ja, TVH ignoriert solche Pakete auch, allerdings nur beim Lesen vom DVB Device.

    Auf der anderen Seite könnten diese aber auch vom ngene Treiber hinzugefügt werden, weil sonst keiner das Problem hat. Und wenn es das CAM erzeugen würde, dann würde das auch bei anderen auftreten.

    DD wird das im ngene Treiber nicht fixen und ich kann das nicht suchen, weil ich weder die Hardware, noch ein Datenblatt von der Karte und den verbauten Chips habe.


    Selbst wenn es ein Treiber Problem ist, so kann man keine existierenden alten Kernels patchen, somit sollte es das UserSpace Program entfernen, so wie TVH das auch tut.


    Man könnte es auch ins ddci2 Plugin einbauen, aber:

    Ich weiß jetzt nicht ob der ngene Treiber auch das redirect unterstützt, aber falls ja, dann muss man das im VDR filtern, weil man dann ohne ddci2 Plugin arbeitet.


    LG,

    Jasmin

    Ich kann mir nämlich nach wie vor nicht erklären, woher diese Pakete kommen sollen...

    Vielleicht sind es NULL Pakete.

    In TVHeadend findet sich dieser Code:

    Code
    1. /* Ignore NULL packets */
    2. if (pid == 0x1FFF)
    3. goto done;

    Vielleicht sind es NULL Pakete.

    Man könnte in ddci2 (oder schon im VDR) vor und nach dem CAM auf diese Pakte überprüfen und damit herausfinden, ob diese Pakete vom ngene Treiber oder der Cine 5.5 erzeugt werden. Könnte ja sein. Ich meine wenn sie am Eingang von ddci2 nicht da sind, am Ausgang aber schon.

    Wie schon weiter oben gesagt, der ngene Teil im Treiber ist mangels Hardware nicht besonders getestet worden.

    Und der Original DD Treiber kann die ngene Karten gar nicht mehr (soweit ich mich erinnere).

    LG,

    Jasmin

    Falls du es nochmals mit yaVDR versuchen möchtest, könntest du nach der Installation mal nachschauen, ob du überhaupt eine Netzwerk Device hast.

    Kannst du mit "ifconfig -a".

    Wenn das da ist, dann kannst du das Netzwerk ja manuell konfigurieren.

    Wenn nicht, dann ist es ein Treiber Problem.

    LG,

    Jasmin

    Vielleicht könnten die yaVDR Entwickler eine 0.6.2 machen, die dann mein media-build-dkms verwenden, statt dem alten von Oliver.

    Eigentlich war die Intention des neuen DKMS Paketes, es für yaVDR zu verwenden.


    nst hat in der Zwischenzeit wieder einige Patches von DD in den Kernel gebracht und auch einige Unschönheiten entfernt. Wäre Zeit für eine 0005 Version des DKMS Pakets. Ich bin derzeit auf Urlaub und kann deshalb bis Februar kein neues bauen.


    LG,

    Jasmin

    Ehrlich gesagt frag' ich mich an der Stelle ja, ob die Effekte beim/im IRQ Handling auch auf Windows-Setups auftreten

    Der Gedanke ist sehr gut!

    Könnte vielleicht einer der Betroffenen mit WIndoof und einer entsprechenden Abspiel-SW versuchen das Problem zu reproduzieren?

    Tritt es auch auf, dann ist es wohl die Board-HW in Verbindung mit der DD HW und wir können die Linux Treiber mal ausschließen.

    Das wäre auch für DD sicher hilfreich zu wissen.


    Bei DD gibt es sowohl einen Windoof/FPGA Entwickler und einen Linux Entwickler. Die könnten dann ev. das Problem endlich fixen.

    Ich weiß aber, dass sie das Problem haben, es nicht reproduzieren zu können und dann kann man es als Entwickler schlecht bis gar nicht finden (habe selbst öfter dieses Problem). Auch wenn es nur alle heiligen Zeiten auftritt ist das sehr schwer, wenn man FPGA und Treiber debuggen muss.


    LG,

    Jasmin

    Danke für's testen Grillbert!


    Die Warnung dass die (de)installation lange dauern kann hatte ich unterschätzt... mehr als 24 STD hat mein Apollo Lake Celeron gebraucht um die Module von allen alten Kerneln (waren einige) zu entfernen...

    Nun ja, dazu habe ich aber einen Patch für DKMS gemacht (dkms_speed.patch in dem Beitrag).


    - Leider kämpfe ich immer noch mit I2C Timeouts bei meinem Setup. (Tritt alle paar Stunden Betrieb auf)

    Ping mal nst an, vielleicht kann er dir beim Debuggen helfen. Er suchst schon länger nach der Ursache.


    LG,

    Jasmin

    Ich bin derzeit wieder sehr mit dem Kernel und dem media_build DKMS für die neuen Treiber beschäftigt.

    Und danach mache ich mal ein paar Tage Urlaub.


    Ich kann mir das also erst in ein paar Wochen ansehen und es gibt ja bei live noch andere offene Wünsche.

    Gut, dass du einen Request gemacht hast, so wird es nicht vergessen.


    Machbar ist das sicher, sofern die Daten verfügbar sind.

    Was mich dann gleich zur Frage an die EPG Data Kenner bringt, ob die Info irgendwo verfügbar ist?


    LG,

    Jasmin

    ausser dass das femon-plugin keine Signalstärken mehr anzeigt

    Das wird wohl daran liegen, dass die neuen Treiber nur DVBv5 API sprechen und Femon das nicht kann.


    Lasse ich aber mal über alle neuen Module ein modprobe laufen, gibt es diverse, die sich nicht laden lassen und die vielleicht jmd. anders braucht.

    Code
    1. modprobe: ERROR: could not insert 'adv7511': Unknown symbol in module, or unknown parameter (see dmesg)
    2. .....

    Super! Vielen Dank fürs testen!

    Jetzt hab ich zwar einen Haufen Arbeit, aber vielleicht komme ich noch vor dem Urlaub dazu.


    Ich weiss nicht, ob das Entfernen der Originalmodule eine gute Idee ist. Normalerweise sorgt die Priorisierung der Module unter updates dafür, dass das gewünschte geladen wird - und wenn man das dkms entfernt, hat man wieder den vorigen Zustand.

    Problematischer ist es, wenn Module umbenannt worden sind, weil dann i.d.R. wie bei lirc_serial Konfigurationsarbeiten notwendig sind, oder wenn sich Parameter geändert haben.

    Also so einfach ist das nicht mit DKMS.

    Das stimmt zwar für Ubuntu, aber nicht für andere Distributionen. DKMS hat da ein paar Sonderbehandlungen implementiert. Generell ist der Ansatz von DKMS die ersetzten Module in den DKMS Tree zu verschieben. Beim Uninstall werden sie dann wieder zurück verschoben.

    Mit meiner Script Ergänzung hätte dasselbe mit den umbenannten/entfernten Modulen passieren sollen, aber für das Wiederherstellen brauche ich dann den leider nicht vorhandenen PRE_UNINSTALL Hook in DKMS.

    Bei Ubuntu geht es mit der jetzt implementierten Lösung, weil Ubuntu .../updates/* bevorzugt, wie du geschrieben hast.


    Da wäre etwas mehr Hilfestellung wünschenswert (passende Changelog oder so)

    Das ist sehr schwierig, weil die Änderungen nicht immer ersichtlich sind. Gerade die Sache mit serial_ir liegt schon wieder einige Zeit zurück und ich kann nicht 1000 Commits durchsuchen, ob da was dabei ist was ein Problem darstellen könnte.

    Ich kann nur warten bis mir User was sagen und das ev. ins README oder changelog schreiben. Wobei im changelog ist es irgendwann auch aus den Augen und damit wertlos.


    LG,

    Jasmin

    Ich habe das nsecs_to_jiffies Problem gelöst!

    Die neuen Pakete sind bereits auf Launchpad.


    Hier der Test:


    Der entsprechende Patch für media-build ist auch schon auf der Media Liste gepostet worden.


    Ich habe auch die Sache mit den nicht mehr erforderlichen Modulen gebaut, allerdings kann ich das nicht perfekt machen, weil DKMS keinen PRE_UNINSTALL Hook hat. Deshalb ist das vorerst einmal deaktiviert.

    Wer es trotzdem ausprobieren möchte, kann das handle_updated_modules.sh Skript nach der Installation ausführen.

    Dieses löscht oder besser verschiebt die nicht mehr erwünschten lirc Module (kann man jederzeit um neue Module erweitern) in den DKMS Baum.


    Code
    1. $ cd /var/lib/dkms/media-build/0004/build
    2. $ ./handle_updated_modules.sh /var/lib/dkms/media_build/0004/<kernel-version> \
    3. <kernel-version> <arch> install
    4. Bei sieht das so aus:
    5. $ ./handle_updated_modules.sh /var/lib/dkms/media_build/0004/3.13.0-117-generic/x86_64 \
    6. 3.13.0-117-generic x86_64 install

    Mit "uninstall" als action Parameter macht man es wieder rückgängig.


    Ich werde versuchen bei den Maintainern von DKMS den PRE_UNINSTALL Hook zu bekommen. Ohne diesen kann man das zwar auch verwenden, aber meiner Meinung nach nur zum Entfernen, weil man sicher vergisst vor dem nächsten Kernel Update ein Restore zu machen.

    Auf der anderen Seite ist das vielleicht gar nicht nötig, weil wenn man sich schon für die DKMS Treiber entschieden hat, dann braucht man nicht mehr zurück steigen und wenn man das wirklich will, dann braucht man ja nur das ganze "/lib/module/<kernel-version>" Verzeichnis vor der Installation sichern, um es bei Bedarf wieder herzustellen zu können.

    Oder man installiert einfach alles neu aus den entsprechenden Paketen.


    LG,

    Jasmin

    Das hat der Gute Thomas in diesem Commit eingebaut:



    Ich kann nur nicht rückwirkend ein Symbol exportieren, welches sich im Kernel Tree befinden.

    Aber ich kann in media_build/v4l/compat.h eine passende inline Funktion definieren und diese bei Bedarf (Export in time.c oder

    timers.c fehlt) einschalten. Aber wie gesagt, das dauert ein wenig.


    LG,

    Jasmin