Beiträge von TomJoad

Mein ks0108 ist wie auf der rebach-homepage beschrieben angeschlossen und funktioniert (also display pin 4 auf parallel pin 17). Allerdings ist nur für den größten Bereich der Kontrastregelung kein Bild zu erkennen, das ist ziemlich fummelig.
Vielleicht hilft es.

Fertige Pakete für linvdr auf Basis Debian Woody sind halt oft veraltet oder man findet nichts mehr, vieles muss aus den Sourcen neu übersetzt werden - manches laesst sich aber nicht mehr uebersetzen wegen des veralteten gcc.
Es gibt zwar geglueckte (?) Ansätze mit neuerer Entwicklungsumgebung, aber mir verursacht z.B. die Userthread-Bibliothek von Woody mehr Bauchgrimmen und eine neue clib bedeutet normalerweise auch eine neue Systemversion.
Gegen einen Update spricht, dass die neue Version wahrscheinlich nicht ganz so schlank daherkommen kann und deshalb ältere, stromsparende Hardware evtl verschrottet werden muss.
Solange die neuesten Kernel noch laufen und das Laden/Entladen von Modulen noch fkt. bleibe ich aber erstmal bei linvdr 0.7 als Basis (mit allen notwendigen Ergänzungen, siehe Signatur).

Das ist bei mir genauso. Deshalb habe ich die FB von der Airstar2 angelernt, die funktioniert bei direkter Sicht aus jedem Winkel und auch aus größerer Entfernung. Es liegt also nicht am Empfänger, sondern an der FB.

Also, bei meiner TT war eine Beschreibung dabei

Zitat

An der vorderen Blende der CI-Erweiterung befindet sich ein Infrarotsensor für die Fernbedienung. Achten Sie bitte darauf, dass der zugehörige Jumper gesteckt ist. Wenn Sie schon eine Fernbedienungsmöglichkeit an der DVB-Karte selbst haben, können Sie diese dort weiterhin verwenden, wenn Sie den Jumper an der CI-Erweiterung entfernen

Bei mir war der Jumper im Auslieferungszustand bereits gesteckt. Der Jumper befindet sich von der Anschlussseite gesehen, links von der Pfostenleiste.

Gegenüber früher fehlen in der ...refactoring/v4l/compat.h

#include <linux/i2c-id.h>
#include <linux/pm.h>
#include <linux/version.h>
#include <linux/utsname.h>
#include <linux/sched.h>

Wenn man die einfügt, geht es wieder - offiziell ist aber wohl die Antwort von e9hack

Die Meldung könnte kommen, wenn Du nicht den passenden Treiber für Deinen IDE-Chipsatz installiert hast.
Beim Intel-Controller, den Du vermutlich nichts hast, sollte dmesg etwas ähnliches zeigen wie:

PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x7cf0-0x7cf7, BIOS settings: hda:DMA, hdb:DMA

Man bräuchte mehr Informationen über die Hardware, den eingesetzten Linux Kernel und die Kernel-config. HDIO_SET_DMA failed muss in der Kernel-Konfiguration behoben werden

Nichts für ungut, aber hast Du w_scan mit -Q laufen lassen? Meine TT-C-2300 hat keine Probleme mit QAM256.

Zitat

Original von Toxic-Tonic
Hast du irgendwo eine Info wo das Plugin herkommt? Vor allem ist es für die Mahlzeit-Version richtig?

Diese Version habe ich mal eingestellt. Sie unterscheidet sich von der Original-tt-Version nur duch Abfangen der Bedingung ChannelNumber == 0 (ohnedem stürzt beim Hochfahren der VDR ab bei einigen Usern - auch bei mir).
Alternativ kann man jetzt auch das graphlcd-plugin 0.1.5 verwenden mit den zugehörigen Libraries, da ist dieser Patch auch drin.

Ich weiss nicht mehr, wo ich es hergeholt hatte, aber libexif-0.6.13 liess sich mit configure und make ohne Probleme übersetzen. Damit funktioniert auch das Plugin.

dvd666:
Schalte mal CONFIG_VIDEO_V4L1 zusätzlich ein, es gibt da Abhängigkeiten

powarman
Danke, dass Du alle meine Änderungen übernommen hast. Es läuft jetzt fast perfekt. Fehlt nur noch eine kleine Sache, die mir erst später aufgefallen war, wo ich mit freetype2-Unterstützung übersetzt habe:
Es fehlt in glcdgraphics/font.c
#include <unistd.h>
Sonst kommt beim Übersetzen bei mir

g++ -g -O2 -Wall -Woverloaded-virtual -fPIC -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 font.c
font.c: In method `bool GLCD::cFont::LoadFT2(const string &, const string &, int, bool = false)':
font.c:188: implicit declaration of function `int GLCD::access(...)'

Jedenfalls noch mal danke, das ist eines meiner wichtigsten Plugins.

fuf:
Hast du geschaut, dass nicht noch die alte Version von libglcddrivers.1.0.0 herangezogen wird? (Nur eine Version im Bibliothekssuchpfad, ldconfig). Das führt mit Sicherheit zum Absturz.

@toxic-toxic:
Ich habe die Base-Libraries von graphlcd-0.1.4 in woody-Umgebung mit gcc 2.95.4 übersetzen können. Was ich dazu brauchte, steht im thread zum diesem plugin (threadid=60469). Allerdings, wie auch von anderen bestätigt, geht ohne Eingreifen in den Code die direkte Ausgabe auf Port nicht, nur die Ausgabe über parport-Modul.

Das ist merkwürdig. Intern läuft es auch nicht anders, nur dass poweroff.pl vom VDR als Reaktion auf die Poweroff-FB-Taste aufgerufen wird. Dann wird vom init-Prozess /etc/init.d/rcShutdown gestartet, das intern einen runvdr stop macht.
Interessant wäre ein ps -ef nach einer Weile wenn versucht wurde, per FB zu beenden. Eigentlich sollte bald nach dem Protokollieren von poweroff.pl im log-output ein Signal 15 auftauchen.

So auf die Schnelle geantwortet, bin ich noch nicht klüger, die Dateideskriptoren mit EOVERFLOW sind wahrscheinlich /dev/../demux.. (lsof -p pid sagt könnte das bestätigen), und das ist nur die andere Seite von den "ringbuffer overflow" - Meldungen. Irgendwas scheint da sehr träge zu sein im System.

Ich wollte noch was anderes loswerden, weil es auch in diesen thread reinpasst.
Ich habe jetzt endlich Zeit gehabt, die Repacker-Meldungen beim Aufnehmen mit Artefakten in der Aufnahme genauer zu untersuchen.
- Da die Meldungen immer mit TS continuity Fehlern zusammen kamen, habe ich die Kontinuitätsprüfung für eine ausgewählte Pid (101 von ARD) immer weiter nach vorne gelegt, vom remux.c nach cDevice::Action bis in den av7110-Treiber.
Dort speichere ich in der av7110-Struktur einen Zähler und überprüfe in processDmaRx für jedes TS-Paket, das zu dieser Pid gehört und PAYLOAD gesetzt hat, ob der Zähler um 1 erhöht ist, sonst gebe ich eine Meldung aus und die Bytes 1-3 jedes Paketes.
- Ich finde folgendes in Buf[3] für Pid 101 (ARD) (hex) wenn ein Problem auftritt:
19,1a,19(!),1a,1b,1c,1d,1e,1f,10,11,12,13,14,15
oder: 17,18,19,1e(!),1f,10,11,12,13,14,15,16,17,18,19,1a,1b
oder: 13,14,1c(!),1d,1e,1f,10,31,12,13,14,15,16,17,18
oder: 1a,1b,1c,19(!),1a,1b,1c,1d,1e,1f,10,11,12,13,14,15,16,17,18
oder: 1e,1f,16(!),17,18,19,1a,1b,1c,1d,1e,1f,10,11,12,13
oder: 1c,1d,1e,14(!),15,16,17,18,19,1a,1b,1c,1d,1e,1f,10,11
Merkwürdigerweise ist von 21 Paketen immer eines der ersten 5 Pakete nicht ok ???! (worauf kann das hindeuten?)
Buf[0] steht normalerweise auf 0x0, manchmal auch auf 0x40. TS_ERROR ist nicht gesetzt.
- Dolby ist bei mir ausgeschaltet, weil ichs nicht brauche, zu sehen sind als pids 101,102,18,104 (Transfermode schaltet explizit 101,102,104 ein).
- Die angezeigten und nur die hier gefundenen Kontinuitätsprobleme führen später zu Meldungen des Repackers.
- Ich finde nach einem channelswitch immer zuerst kleine Pufferlängen(940 oder 752...), dort natürlich erstmal ungültige Segmente, aber später dann fast immer 3948 (max. Länge, die in den 4k-Puffer reinpasst).
- Die Frequenz der Störungen liegt bei meist 2-4 Minuten Abstand.
Nicht alle Störungen sind als Klötzchen sichtbar, aber etwa die Hälfte.
- Ohne gleichzeitige Aufnahme sind aber nie wahrnehmbaren Störungen im Bild, das Frontend meldet keine UNC, ab und an mal eine 1 in BER.
- Ausgabe der dma_rx->offset,debitype,debilen[idx] während der Bearbeitung eines fehlerhaften Puffers zeigt, dass von den 8 Puffern nur dieser eine Puffer belegt ist.(Deshalb bringt auch eine Erhöhung von DMA_RX_BUFS nichts, ebensowenig war Ersetzen von tasklet_schedule durch tasklet_hi_schedule erfolgreich war).
- Andere Situationen, wo der Transferpuffer voll läuft oder die Puffer geleert werden wegen "consecutive poll timeouts" haben dramatischere Auswirkungen auf die Aufnahmequalität
- Problem tritt mit alter Firmware (2622,261d) genauso auf
- Folgerungen: Repacker und PES packet shortened Meldungen kommen, weil mitten in einem RX_BUF (4k) - Puffer, der mit debiread gefüllt wird, TS Pakete fehlen.
Probleme in der Pufferbehandlung im av7110-Treiber oder im Demuxer scheiden damit aus, vdr und Repacker sowieso?
Auch Rechnerbelastung oder Interruptverteilung/Hardware sind für dieses Problem nicht relevant (wohl vielleicht für andere mit rx buffer overflow)?
- Wenn es ein Ringpufferüberlauf im Kartenspeicher (Hardware) wäre, müssten dann die fehlenden Pakete nicht immer am Ende bzw. am Anfang eines RX-Puffers sein?
- Muss ich mir wirklich zum Aufnehmen eine zweite (Budget-)Karte kaufen?
- Ohne tiefere Einsicht in die Firmware und den Ablauf auf der Karte komme ich hier nicht mehr weiter.

imho kann man dies Ergebnis nicht verallgemeinern. Ich habe diese Overflows des Transferpuffers auch.
Bei mir kommen viele EAGAINS auf die Ausgabe auf /dev/video0 und manchmal auch "polling timeouts". Ein strace auf den Transfer-thread mit Zeitstempel zeigt oft 300 ms Wartezeiten bis die nächste Ausgabe gemacht werden kann.
Auf jeden Fall ist die Ausgabe langsamer als von /dev/dvr0 der Input kommt und es laufen so langsam die Puffer voll. Das gleiche Problem habe ich auch, wenn ich über das Netzwerk streame.
Es scheint besser zu laufen, wenn ich tasklet_schedule durch tasklet_hi_schedule nur bei TX ersetze, aber da sammle ich noch Erfahrung.
Sollte man rx buffer overflows haben (die ich bei meiner Hardware allerdings nicht sehe) und diese durch mehr RX Puffer verhindern können, kommt doch eigentlich noch mehr Input - oder sehe ich da etwas grundsätzlich falsch?
Gruß
J.

Wenn ich wüsste, welche Patches scharf geschaltet sind (Make.config), käme ich auch so weiter.
Gruss
J.

Ich bekomme meinen üblichen Segmentation Fault beim Starten in
cGraphLCDState::SetChannel
(Aufruf mit ChannelNumber 0).
Das ist mit graphlcd-plugin 0.1.4 behoben, dies macht aber andere Probleme.
Da deine aktuellen Sourcen nicht unter vdr-online sind, kann ich keine Korrektur einbauen
Gruss
J.

poweroff.pl kann man auch ohne Parameter direkt aufrufen. Dann sollte der vdr runterfahren oder eine Fehlermeldung ausgeben.
Intern wird vom Skript nach evtl. Setzen eines Wiederaufwachalarms
busybox poweroff aufgerufen.
Wenn in der /etc/inittab noch eine Aktion mit poweroff verknüpft wird, wird dieses Skript dann aufgerufen, sonst der Rechner unmittelbar runtergefahren.

Wenn du einen FB-Anschluss an der TT-Kabelkarte hast , kannst Du auch die Airstar-FB direkt anlernen. Allerdings ist am TT-C2300 der FB-Anschluss nur da, wenn man eine CI-Erweiterung dazugekauft hat.
Gruss J.