Beiträge von e9hack

Zitat

Original von wilderigel
Gibts da ned ne interne Funktion, die VDR anweist sofort zu speichern?

Keine Ahnung, muß ich mal suchen.

Eigentlich habe ich schon erwartet, daß sich der VDR eine geänderte Kanalliste merkt, wenn über die Fernbedienung ausgeschaltet wird.

Gruß
e9hack

Kann man irgendwo einstellen, daß die Debug-Infos ins Logfile gehen oder läßt sich das nur über setup.conf ändern?

Gruß
e9hack

Zitat

Original von wirbel
Erst nach ner ganzen Weile speichert dann VDR und du hast ne gefüllte channels.conf. Steht ja auch so in der README. Ein Stündchen solltest du VDR schon Zeit geben..

Wenn ich das Reelchannelscan-Plugin laufen lasse und Aus/Ein-Schalte sind alle gefundenen Kanäle noch da.

Gruß
e9hack

Hi,

speichert das Plugin auch die Kanäle? Ich starte mit einer channels.conf, wo nur ARD drin steht. Nach dem Scan sind 88 oder 101 Kanäle da (245..265 ist Soll). Nach dem Aus/Ein-Schalten kennt der VDR nur die Kanäle, die auf dem ARD-Transponder mit drauf sind.

Gruß
e9hack

Zitat

Original von wilderigel
Mit den Standard DVB Includes von Debian lässt es sich auf jeden fall aml nicht kompilieren:

Wohl doch zu alt ...

Ich hatte das gleiche Problem. Nach entfernen von
#include <linux/videodev2.h>
in common.c konnte ich es kompilieren.

Gruß
e9hack

Zitat

Original von e9hack
Es sieht so aus, daß die KNC One, Terratec Cinergy 1200 und Satelco EasyWatch baugleich sind.

Laut Windows-Treiber-Id ist die Satelco EasyWatch eine (uralte) TT-Budget mit VES1820.

Gruß
e9hack

Zitat

Original von Dr. Seltsam

Neben der Cinergy gibt es auch noch die KNC One, von der man munkelt, es sei das baugleiche Original zur Cinergy. Bei beiden gibt es aber wohl Fälle, wo das CI nicht laufen will.

Es sieht so aus, daß die KNC One, Terratec Cinergy 1200 und Satelco EasyWatch baugleich sind. Der verwendete Demodulator (TDA10021) scheint zwar mit QAM256 zu funktionieren, aber mit der Spec siehts genauso bescheiden aus wie beim STV0297.

Von der Cinergy 1200 scheint es allerdings zwei Varianten zu geben. Ob die neuere auch den TDA10021 hat, ist unklar.

Zitat

was anderes:
UFO hat vor ein paar Stunden den Patch
[saa7146_i2c] short_delay mode fixed for fast machines
ins hg gestellt, der wohl als Ergebnis Eurer Diskussion entstanden ist. Du hast nun in der ML drei weitere Patches veröffentlicht. Sind die zusätzlich oder evtl. überlappend zu dem o.g. Patch?

Die Patches beseitigen das gleiche Problem. Die zusätzliche Wartepause bei den I2C-Transfers bei schnellen PCs wird beseitigt. Der STV0297 kann dann auf QAM256 modulierte Kanäle synchronisieren.

Die IRQ-Behandlung vom SAA7146 ist unsauber. Es könnte Aussetzer beim Transfer über den SAA7146 geben. Der erste von meinen drei Patches sollte dies beheben. Dies gilt für alle Karten mit dem SAA7146.

Zitat

bzw. lassen sie sich auf das HG inkl. des o.g. Patches noch anwenden?

Die Patches lassen sich weiterhin anwenden.

Gruß
e9hack

Zitat

Original von skiller2k1
Der lokale NTP-Server holt sich die Zeit von unterschiedlichen öffentlichen NTP-Servern und nimmt davon die am besten synchronisierte Zeit.

Woher weißt Du, welcher von den unterschiedlichen öffentlichen NTP-Servern die am besten synchronisierte Zeit hat??

Gruß
e9hack

Bei mir steht im syslog:

Oct 29 09:29:56 very-new-darkstar kernel: eth2: no IPv6 routers present
Oct 29 08:29:56 very-new-darkstar ntpdate[3465]: step time server 130.133.1.10 offset -3600.072238 sec

Gruß
e9hack

Zitat

Original von oli33
So was hab ich getan:

in /usr/local/src/DVB/v4l/Makefile folgende Zeile auskommentieren:

#KDIR := /lib/modules/$(KERNELRELEASE)/build

und durch diese ersetzen:

KDIR := /usr/src/linux-2.6.16.21-0.25

Alles anzeigen

Das hilft nicht wirklich. Es gibt noch einige Scripte, die direkt /lib/modules/'Kernel-Version über uname -r'/build benutzen.

Zitat

Aber nun alter Fehler weg -dafür neuer da ....:

WARNING: Symbol version dump /usr/src/linux-2.6.16.21-0.25/Module.symvers
is missing; modules will have no dependencies and modversions.

/bin/sh: scripts/genksyms/genksyms: No such file or directory

Jetzt fehlen noch ein paar Dateien. Kopiere die von /usr/src/linux-2.6.16.21-0.25-obj/i386/default nach /usr/src/linux-2.6.16.21-0.25.

Wenn Du auf die Neukonfiguration (make config) verzichtet hättest, würde das Compilieren auch ohne jegliche Änderung funktionieren.

Gruß
e9hack

Zitat

Original von Dr. Seltsam
dann wäre ja nun mal interessant, ob die 1500C auch Probleme mit QAM256 hat. Ich kann`s leider nicht testen, weil ich an einer Kopfstation der ewt hänge (Genossenschafts-Wohnanlage). Da gibt es nur QAM64.

Es würde mich auch interessieren, ob QAM256 funktioniert, da ich mir eine zweite Karte zulegen will. Eine große Auswahl hat man ja nicht mehr, nur noch TT-1500C, Cablestar2 oder Cinergy 1200.

Gruß
e9hack

Zitat

Original von oli33
Also ich hatte ja den XEN-Kernel im Verdacht (habe gestern Abend damit rumgespielt). Ergo alles von vorn, Server Reboot mit "normalem" Kerneln, DVB neu runterladen, entpacken usw...

und siehe (eben nicht) da:

server01:/usr/local/src/DVB # make menuconfig
make -C /usr/local/src/v4l-dvb/v4l menuconfig
make[1]: Entering directory `/usr/local/src/v4l-dvb/v4l'
make -C /lib/modules/2.6.16.13-4-default/build -f /usr/local/src/v4l-dvb/v4l/Makefile.kernel config-targets=1 mixed-targets=0 dot-config=0 v4l-mconf
make[2]: Entering directory `/usr/src/linux-2.6.16.13-4-obj/i386/default'
/usr/local/src/v4l-dvb/v4l/Makefile.kernel:22: Makefile: No such file or directory
make[2]: *** No rule to make target `Makefile'. Stop.
make[2]: Leaving directory `/usr/src/linux-2.6.16.13-4-obj/i386/default'
make[1]: *** [/lib/modules/2.6.16.13-4-default/build/scripts/kconfig/mconf] Error 2
make[1]: Leaving directory `/usr/local/src/v4l-dvb/v4l'
make: *** [menuconfig] Error 2
server01:/usr/local/src/DVB #

alles beim alten - XEN ist damit wohl auszuschließen. Ich suche weiter, evt. hat ja noch jemand eine Idee

Alles anzeigen

Suse hat verschiedene Kernelkonfigurationen. Normalerweise sollte der build-Link auf die Kernel-Sourcen zeigen. Bei Suse zeigt er in ein separates Verzeichnis, wo nur die entsprechende Kernelkonfiguration abgelegt ist. Für die meisten externen Treiber ist das zum kompilieren ausreichend. Die hg-Treiber benötigen jedoch die vollständigen Sourcen. Man muß einfach den Link von /lib/modules/'Kernel-Version'/build auf die Kernel-Sourcen verbiegen, meistens /usr/src/linux" oder /usr/src/linux-'Kernel-Version'. Gegebenenfalls ist auch noch .config dahin zukopieren.

Gruß
e9hack

Zitat

Original von Dr. Seltsam

mit dem ersten 18db-Dämpfungsglied habe ich noch nichts bewirkt, aber ein zusätzlicher 12db-Abzweiger brachte dann die ersten Artefakte BER und UNC zeigen dann höhere Werte, aber erst bei extremer Signaldämpfung. Die FuSi hätte da schon längst die Segel gestrichen - habe da ständig dreistellige BER-Werte.
Scheint also ein exzellenter Tuner zu sein !

Vergleiche zwischen unterschiedlichen Demodulatoren bringen nichts, da die Werte für BER unterschiedlich skaliert sind. Beim VES1820 (FuSi) kann man die Anzahl der Bits, die zur BER Berechnung benutzt werden, programmieren. Es wird der maximale Wert genutzt. Da für den STV0297 keine Spec verfügbar ist, ist unklar wie der BER-Wert skaliert wird.

Zitat

Ist das wirklich genau der gleiche wie auf der Nexus-CA?

Die Blechbox auf beiden Karten ist unterschiedlich groß. Es weden auch unterschiedliche PLL-Chips benutzt.

Gruß
e9hack

Zitat

Original von Dr. Seltsam
ich habe den Patch nexusca-berunc.diff angewandt, habe aber bei meiner TT 1500C (die auch stv0297 nutzt), keinerlei Veränderung an der femon-Anzeige. Ist der Patch denn nur Nexus-CA-spezifisch?

Der Patch ist nicht Nexus-CA-spezifisch. Die TT 1500C benutzt zwar eine andere Init-Tabelle für den STV0297, die sich gegenüber der TT 2300C geringfügig unterscheidet. Meine TT 2300C läuft aber auch mit der anderen Init-Tabelle.

Zitat

oder muss das femon-Plugin noch angepasst werden?

Es muß nichts am Plugin geändert werden. Ich habe auch einige Transponder, bei denen BER 0 ist.

Was passiert, wenn man das Signal schlecht macht (z.B. Dämpfungsglied)?

Gruß
e9hack

Zitat

Original von arghgra

Diese Aussage ist eben relativ ...

Aber worum es mir eigentlich geht: Technotrend hat zumindest einen Treiberpatch für Budget-Karten nachgelegt, der deren Empfangsverhalten für Qam256 verbessert (verbessern soll). Für FF-Karten soll es wohl auch was geben - ich konnte jedoch keine neue Treiberversion identifizieren (alles aus dem Announcement aus dem dvbshop-Supportfurom).

Es gibt keinen Treiber-Patch von Technotrend für QAM256. Technotrend hat lediglich eine Ini-Datei geändert, damit QAM256 in der Auswahl der Sendersuche erscheint. Was da nachgetragen wurde, konnte man auch selber ändern, da alle nötigen Infos in der Ini-Datei dokumentiert sind.

Gruß
e9hack

Zitat

Original von UFO

Ich bin nicht sicher, ob der Interrupt-Code überhaupt jemals funktioniert hat.
Wenn Du es hinbekommst, wäre diese Variante natürlich vorzuziehen...

So wies aussieht, müssen nur die Zugriffe auf IER und IEN vom SAA7146 per Spinlock interruptfest gemacht werden. Dann bleibt der VDR beim zappen nicht mehr hängen. Aufnehmen scheint auch zu funktionieren.

Gruß
e9hack

Zitat

Original von arghgra
Kann ich den Sinn des Patches derart zusammenfassen: Er verbessert das Tunen von Qam256-Kanälen auf TT 2300 DVBc-Kanälen?

Ich würde die Funktion mal so zusammenfassen:

1) Bei langsamen PCs mit TT-2300C ändert sich nichts.
2) Bei schnelleren PCs mit TT-2300C, bei denen QAM256 bisher nicht empfangbar war, ermöglicht der Patch das Synchronisieren des Demodulators.

Der Patch verbessert prinzipiell nichts, wenn das Signal zu schlecht ist (Pegel oder Störabstand).

Zitat

Wie sieht es mit der Empfangsqualität (BER/UNC) mit und ohne Patch aus?

Der Patch hat darauf keinen Einfluß. Damit BER/UNC bei Karten mit STV0297 überhaupt Werte liefert, ist ein weiterer Patch notwendig.

Gruß
e9hack

Zitat

Original von UFO

Wie wäre es mit folgendem Patch?

Diff

diff -r 1743615a44e1 linux/drivers/media/common/saa7146_i2c.c
--- a/linux/drivers/media/common/saa7146_i2c.c  Thu Oct 19 13:17:43 2006 +0200
+++ b/linux/drivers/media/common/saa7146_i2c.c  Thu Oct 26 02:40:05 2006 +0200
@@ -218,11 +218,9 @@ static int saa7146_i2c_writeout(struct s
                }
                /* wait until we get a transfer done or error */
                timeout = jiffies + HZ/100 + 1; /* 10ms */
+               /* first read usually delivers bogus results... */
+               saa7146_i2c_status(dev);
                while(1) {
-                       /**
-                        *  first read usually delivers bogus results...
-                        */
-                       saa7146_i2c_status(dev);
                        status = saa7146_i2c_status(dev);
                        if ((status & 0x3) != 1)
                                break;
@@ -233,10 +231,10 @@ static int saa7146_i2c_writeout(struct s
                                DEB_I2C(("saa7146_i2c_writeout: timed out waiting for end of xfer\n"));
                                return -EIO;
                        }
-                       if ((++trial < 20) && short_delay)
+                       if (++trial < 50 && short_delay)
                                udelay(10);
                        else
-                       msleep(1);
+                               msleep(1);
                }
        }

Alles anzeigen

Das Verschieben des Dummy-Zugriffes aus der Schleife reduziert die Zahl der I/O-Zugriffe.

Ich habe vor einer reichlichen Woche die Abbruchgrenze auf 100 hoch gesetzt. Das läuft ohne Probleme. Die 50 sollte aber auch reichen, da ja der kritische Wert bei ca. 20 liegt.

Ich habe auch die IRQ-Variante probiert. Da hing der VDR nach 3..4 mal zappen. Im Log stand irgendeine Timeout-Fehlermeldung. Ich denke mal, daß die I2C-Routine auf den falschen Interrupt fom SAA7146 reagiert hat.

Gruß
e9hack

Hi,

es sieht so aus, daß die Anzahl der Seiten im Thread nicht stimmt, wenn der letzte Beitrag im Thread auf einer neuen Seite steht.

z.B.: Die Akte A8N-VM CSM mussen doch fonktionnieren

Der Thread hat keine Seiten-Links (vorherige, nächste, ...), da scheinbar alle Beiträge auf einer Seite sind. Erste der Link Letzter Beitrag führt zum wirklich letzten Beitrag, der dann auf einer neuen Seite steht. Ich habe das auch schon bei Threads gesehen, die über mehrere Seiten gehen. Wenn es dann eine weitere Nachricht gibt, sind diese und die vorherige wieder über die Seiten-Links erreichbar.

Gruß
e9hack

Zitat

Original von UFO

Btw, wie hast Du die Zeiten gemessen?

Ich habe keine realen Zeiten gemessen. Ich habe einen zweiten Counter eingebaut, der die Aufrufe von msleep() in der Schleife mitzählt und dann beide Zähler am Ende per printk() ausgegeben.

Zitat

Auf meinem - relativ langsamen - PIII-System wird mit DVB-S-Karten udelay(10) nur 2-3 mal aufgerufen.
Rechnerisch entspricht 275kHz 3,6us Periodendauer, bei 137,5kHz also 7,2us pro Bit. Damit 200us nicht ausreichen, muß der Demod also auch noch den I2C-Zugriff verlangsamen, oder?

Der SAA7146 kann per Registerzugriff maximal 3 Byte übertragen. Das ergibt mindestens 3 x 9 + 2 Takte = 210us bei 137,5kHz. Die 2 zusätzlichen Takte sind für Start/Stop. Möglicherweise werden noch Wartetakte zwischen den einzelnen Bytes eingeschoben. So wie es aussieht, bremst ein NOP auch um 9 Takte. Ein 1 Byte Lesezugriff überträgt 2 x 2 Byte, ein Schreibzugriff 1 x 3 Byte. Bei mir rennt ein Athlon64-3500.

Gruß
e9hack