Posts by TomJoad

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.

Was mich stutzig macht, ist bei dem letzten ps.txt der Status DN beim vdr, dh. er wartet ununterbrechbar auf I/O-Ende. Normalerweise währt ein solcher Status so kurz, dass man ihn mit ps nicht erwischt. Es wäre interessant, auf welches Device der vdr da los geht. Wenn der aber hart da hängt, hängt ein strace auf den vdr-Prozess möglicherweise genauso.
Wenn der mc an einer Konsole hängt und an einer anderen Konsole Eingaben möglich sind oder über ssh, kannst Du mal einen strace auf den mc machen?
Gibt es die Ringbufferfehler nur bei Hängesituationen? Sind Wärmeprobleme ausgeschlossen?
Gibt es genug Platz auf allen Dateisystemen, auch für /tmp ???

Ich musste im letzten Jahr im Oktober die Frequenz um 150kHz runtersetzen, jetzt Ende Januar nochmal um 300kHz. Z.Zt. benutze ich auch 500kHz (KDG in München).
Die Frage ist, ob das eine Frequenzverschiebung der Kabelgesellschaft ist, oder ob das eine Alterung frequenzbestimmender Teile der Karte ist (meine Technotrend wurde 12/2005 gekauft). Da das Problem mit anderen Kabelkarten scheinbar nicht auftritt, könnte auch die automatische Frequenznachführung beim STV0297 unter Linux nicht keinen ausreichenden Regelumfang haben.
Vielleicht kann man hier mal ein paar mehr Daten zusammentragen.

Wie schon gesagt, die Abstürze kommen durch den Port-Zugriff. Ausgabe über Parport-Modul habe ich nicht ausprobiert.
Vielleicht funktionieren andere Thread-Bibliotheken in dem Bereich anders, aber für linvdr und Woody-Umgebung brauche ich folgende Änderung

--- plugin.c.orig       Thu Feb  8 17:49:19 2007
+++ plugin.c    Thu Feb  8 18:44:38 2007
@@ -159,11 +159,13 @@
         esyslog("graphlcd: ERROR: Failed creating display object %s\n", mDisplayName.c_str());
         return false;
     }
+/* Verhalten wie 0.1.3 wiederherstellen
     if (mLcd->Init() != 0)
     {
         esyslog("graphlcd: ERROR: Failed initializing display %s\n", mDisplayName.c_str());
         return false;
     }
+*/
     cfgDir = ConfigDirectory(PLUGIN_NAME);
     if (!cfgDir)
         return false;
--- display.c.orig      Thu Feb  8 17:49:26 2007
+++ display.c   Thu Feb  8 18:49:03 2007
@@ -162,6 +162,13 @@


 void cGraphLCDDisplay::Action(void)
 {
+
+    if (mLcd->Init() != 0)
+    {
+        esyslog("graphlcd: ERROR: Failed initializing display \n");
+        return;
+    }
+
     bitmap = new GLCD::cBitmap(mLcd->Width(), mLcd->Height());
     if (!bitmap)
     {

Bei meimem VDR werden DVD+-R einwandfrei gespielt, aber DVD-RWs kann ich nur abspielen, indem ich sie montiere und mit dvdswitch auswähle
Bei DVD-RWs kommt die gleiche Fehlermeldung.

Hi,
diese Schritte habe ich gebraucht, um 0.1.4 zum Laufen zu bringen:
Base-Paket war nur übersetzbar mit:

glcdgraphics/image.h
#include <string>

glcddrivers/drivers.c
#include <stdint.h>

glcddrivers/network.h
#include <unistd.h>

glcddrivers/g15daemon.h
#include <sys/socket.h>

PLUGINS/src/graphlcd/widgets.h
#include <vdr/toolsh> damit uint_64 richtig aufgelöst wird

Dann wurden die Libraries nach /usr/local/lib geschrieben, während die alten unter /usr/lib waren. Nach ldconfig werden bei mir aber die unter /usr/local/lib zuerst gefunden. (Kontroll mit ldd /usr/lib/vdr/plugins/libvdr-graphlcd...)

Dann stürzte vdr immer ab beim Initialisieren des graphlcd-Plugins. Der core zeigte, dass ein Segmentation Fault auftrat beim der ersten direkten Port-Ausgabe, die in
Display->Action angestossen wird (core vom graphlcd-Thread)
Wenn man den open wieder wie in 0.1.3 an den Anfang der Action-Routine verlegt und aus plugin.c entfernt, geht bei mir alles.
Ich nehme an, dass der ioperm nur für den vdr-MainTask gilt, der die Initialisierung des Plugins durchführt, während der graphlcd-Thread dann später eins auf die Finger bekommt.
Meinungen???

Weiterer Vorschlag von mir wäre, mal bei runtergefahrenem vdr alle
graphlcd Einträge in der /etc/vdr/setup.conf zu löschen, damit sie mit Defaultwerten neu angelegt werden .

Gruß

Vielleicht hast Du mehr Glück mit dem Plugin von
http://vdr.nella.de/libvdr-graphlcd.so.1.4.5
als mit der Version von Mahlzeit.

Wenn mir jemand 240kB Upload-Platz zur Verfügung stellt, könnte ich eine gepatchte Version von libvdr-graphlcd-1.4.5 für vdr-1.4.4-2-Toxid-Ed hochladen.

Johann

Hallo,

ich hatte auch seit 8 Wochen auf allen Transpondern ausser 113 MHz viele UNCs und keinen brauchbaren Empfang mehr mit meiner TT-C2300.
Der Patch von frank-km hat Wunder gewirkt. Der Empang ist jetzt besser als unter Windows.
Vielen Dank

Johann

Hallo,
dieses Problem taucht in mehreren Threads auf, ist aber schon früher diskutiert und gelöst worden (Siehe thread 44392). Leider hat der Patch nie seinen Weg ins Plugin gefunden.
graphlcd macht schon beim Initialisieren des Plugins SetChannel(cDevice::CurrentChannel()); bekommt aber immer 0 für CurrentChannel zurück, weil noch gar kein PrimaryDevice festgelegt ist. Warum vdr dann nicht bei allen abstürzt, ist mir unklar, ich jedenfalls benötige den Patch aus obigem Thread unbedingt (am einfachsten ist der erste, wo der Aufruf von SetChannel in cGraphLCDState::cGraphLCDState() einfach auskommentiert wird (graphlcd/state.c).

Johann