Beiträge von SHF

Zitat von fhg

OK... jetzt wirds theoretisch, aber müßten dann beim Senderscan nicht schon Abweichungen erkennbar sein? Der scan zeigte jedenfalls immer die gleichen Frequenzen an.

Ich würde es eher praktisches rumprobieren nennen .

Ob der Scan bei DVB-T2 wirklich die Frequenz ermittelt, oder ob die aus einer empfangenen Tabelle kommt, kann ich nicht sagen.

Ich habe nur SAT und noch nie einen Scan gemacht. Da kommen die Transponder-Frequenzen aus dem DVB-Datenstrom und können durchaus etwas daneben liegen.

(Den Fall hatte ich wegen eines defekten LNB selber und es hatten nur einige der Empfänger im Haus Probleme damit.)

Ich habe mir trotzdem noch mal schnell die Änderungen im Tuner-Treiber angesehen (das komplette TBS-git mit 3,8GiB hatte ich ja eh schon runtergeladen) und da hat sich eigentlich nicht viel getan.

Auffällig ist eigentlich nur, dass da ein Timeout für den "lock" eingeführt wurde. Eventuell ist der für deine Empfangsbedingungen/Tunermodell einfach zu knapp bemessen.

Ich habe den man großzügig vergrößert, das könnte noch einen Versuch wert sein.

Zumal die Änderung minimal ist:

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 4217a34d08f5..1b52aa83de32 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -357,9 +357,9 @@ static int si2157_sleep(struct dvb_frontend *fe)
 
 static int si2157_tune_wait(struct i2c_client *client, u8 is_digital)
 {
-#define TUN_TIMEOUT 40
-#define DIG_TIMEOUT 30
-#define ANALOG_TIMEOUT 150
+#define TUN_TIMEOUT 140
+#define DIG_TIMEOUT 130
+#define ANALOG_TIMEOUT 250
     struct si2157_dev *dev = i2c_get_clientdata(client);
     int ret;
     unsigned long timeout;

Einzuspielen ist der Patch genau wie der Letzte.

Zitat von Paulaner

Na ja, mit ffmpeg funktioniert es auf jeden Fall,

Ich meinte, als ob es hier als Ersatz für VLC taugt, das war anfangs nicht so eindeutig.

Auch im Bezug auf Umschaltzeiten und was für Einstellungen nötig sind.

Man will ja nicht zwei Baustellen gleichzeitig haben, da ist es schön, wenn verwendete ffmpeg-Aufruf erprobt ist.

Das TvHeadend die externen EPG-Informationen DVB-konform in die Streams einbaut hätte ich, ehrlich gesagt, nicht erwartet. Das wäre echt viel Aufwand.

Wenn das EPG, wie bei DVB, schon im Stream mit kommen, dann schon eher.

Wenn Du das EPG via xmltv beziehst, könnte ein Blick auf das vdr-plugin-xmltv2vdr lohnen.

Das letzte mal, dass ich mich mit externen EPG-Quellen beschäftigt habe, ist aber ewig her.

Ganz am Anfang gab es ein paar interessante Sender, die noch kein EPG hatten, aber seit alle relevanten Sender EPG haben ...

Zitat von fhg

ZDF bekommt ein "lock", ARD nicht.

Dann müsste es doch schon am Tuner liegen.

Auf die Frage hätte ich früher kommen sollen, das wäre ein anderes IC und anderer Treiber .

Du könntest mal versuchen die Frequenz in mehreren kleinen Schritten etwas höher oder niedriger einzustellen.

Wenn Du Glück hast , kannst Du den Kanal so "fangen".

Eventuell ist irgend was in der Frequenz leicht daneben und die Karte mit dem neuen Treiber da nicht so gutmütig.

Zitat von Paulaner

Ich habe noch etwas rumprobiert mit den Werten von PROBESIZE und ANALYZEDURATION aber eine wesentliche Verkürzung der Umschaltzeiten konnte ich nicht erreichen. Auch nach dem ich beide Werte ganz aus dem ffmpeg-Befehl gelöscht habe, war keine große Veränderung erkennbar.

Bei meinen Tests mit ffprobe brachte es was.

Es kann aber sein, dass die Werte bei festem Stream-Mapping irrelevant sind.

Zitat von Paulaner

Ich habe die ffmpeg-commandline noch etwas angepasst und das Stream-Mapping aus der ///pipe ... von Telerising übernommen, wie es an TvHeadend übergeben wird.

Einen Unterschied sollte es eigentlich nicht machen.

Deren -copy Optionen pro Stream sollten mit einem globalen -copy für alles identisch sein (letzteres ist aber übersichtlicher ;-)).

Zitat von Paulaner

Die Umschaltzeiten zwischen den Streams sind bei mir ca. 3 ... 6 Sekunden bis Bild+Ton da sind, meistens sind es ca. 4 Sekunden.

Das ist aber schon mal schneller als alles, was ich bei meinen ffprobe Tests hin bekommen habe.

Unter 5,5 Sekunden war da nie möglich.

Zitat von Paulaner

Aufgefallen ist mir noch, dass meist zuerst das Bild nach ca. 2 Sek. da ist und dann dauert es noch 1 ... 3 Sek. ehe dann auch der Ton richtig da ist.

Das kann auch irgendwie mit der Synchronisierung der Streams zusammen hängen.

Es ist ja nicht gesagt, dass die ersten Pakete schon zusammen passende Audio und Video Daten enthalten.

carel hatte noch diese Optionen in seinem Skript:

FLUSH_PACKETS="-flush_packets -1" # 1: flush immediately, reduce latency, 0: increases throughput, -1: automatic

DISCARD_CORRUPT_PACKAGES="-fflags +discardcorrupt"

Das könnte hier was bringen, indem es ungültige Pakete verwirft.

Und dann kann es natürlich auch irgendwie am Ausgabeplugin hängen.

Zitat von Paulaner

Ob es nun allgemeine Fehler im Stream sind, oder vermutlich doch eher ist das das Umkodieren der Audiostreams im ffmpeg nicht optimal konfiguriert. Denn bei der Android-App von Zattoo kommt das nicht vor. Da wird immer nach 2...3 Sekunden zum nächsten Stream geschaltet.

Dann sollten also nach 2-3 Sekunden die nötigen Informationen da sein.

(Umkodiert wird übriges nicht!)

Zitat von Paulaner

Was mir jetzt noch fehlt ist das zugehörige EPG für die IPTV-Streams.

Für TVheadend habe ich dazu bereits eine passende xmltv-Datei. Die müsste man doch eigentlich auch für die IPTV-Streams im VDR verwenden können.

Nur weiß ich momentan noch nicht, wie ich diese mit den IPTV-Streams im VDR verknüpfen kann/muss. Das ist für mich noch absolutes Neuland!

Dazu solltest Du mal ein extra Thema auf machen.

Es gibt mehrere Plugins für externes EPG und ich vermute mindestens eines wird das schon können.

Mit dem Thema kenne ich mich aber null aus.

Zitat von mini73

Vielleicht müsste mal jemand die Ärmel hochkrempeln und das direkt als Plugin umsetzen, damit das Starten/Stoppen von Scripts usw. wegfällt. Ich kann mir vorstellen, dass da auch noch die ein oder andere Sekunde auf der Strecke bleiben könnte.

Die Idee hatte ich schon von Anfang an, beim hbbTV-Plugin hat man diesbezüglich ja schon hervorragende Vorarbeit geleistet.

Zumindest sollte so der Umweg über den "internen" udp-Stream weg fallen und die Puffer da sparen.

Bevor man da aber mehr Zeit rein steckt, wollte ich erst mal sehen, ob das mit ffmpeg überhaupt sinnvoll funktioniert.

Zitat von Paulaner

In KODI wird dies ja so gemacht, dass für verschiedene IPTV-Lösungen es entsprechende PVR-Addons gibt.

Das dann doch eher nicht, da bei jeder Änderung (und diese Internet-Dienste neigen dazu) das Plugin aktualisiert werden müsste.

Ich denke eher in die Richtung das iptv-Plugin irgendwie für die m3u8-Quellen aufzubohren, soweit die enthaltenen Daten unterstützt werden. Die enthaltenen hls/dash Streams sind standardisiert, da besteht zumindest die Chance das aktuell zu halten.

Der Import der m3u8 Playlisten würde dann gelegentlich über ein Skript laufen, das man recht einfach aktualisieren kann.

Und letztlich ist es ja egal, ob das EPG aus einem anderen Plugin kommt, sofern das Skript beide Konfigurationen gleichzeitig aktualisiert.

Bei der Liste mit den freien Streams von weiter oben habe ich schon mit sowas angefangen.

Leider hatte ich da bislang nur kurz Zeit dafür, so weit dass brauchbare channels.conf Einträge raus kommen bin ich noch nicht.

Immerhin sucht es mir schon das beste Programm und die Streams dazu raus. (Allein das das hat länger gedauert, als gedacht.)

Das ist eigentlich recht leicht, den Patch wendet man nach dem Runterladen und vor dem Kompilieren an:

[...]
git clone --depth=1 https://github.com/tbsdtv/linux_media.git -b latest ./media


# Patch in dieses Verzeichnis herunter laden. 
cd media
patch -p1 < ../si2168_tbs6205_v1.diff.txt
cd ..


cd media_build
[...]

Alternativ kann man man die Änderungen auch per Hand machen, es sind nicht viel:

diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c
index 9dc02f7c30c4..f134fba9ed55 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -393,15 +393,15 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
         goto err;
 
     /* that has no big effect */
-    //if (c->delivery_system == SYS_DVBT)
-    //    cmd_init(&cmd, "\x89\x21\x06\x11\xff\x98", 6, 3);
-    //else if (c->delivery_system == SYS_DVBC_ANNEX_A)
-    //    cmd_init(&cmd, "\x89\x21\x06\x11\x89\xf0", 6, 3);
-    //else if (c->delivery_system == SYS_DVBT2)
-    //    cmd_init(&cmd, "\x89\x21\x06\x11\x89\x20", 6, 3);
-    //ret = si2168_cmd_execute(client, &cmd);
-    //if (ret)
-    //    goto err;
+    if (c->delivery_system == SYS_DVBT)
+        cmd_init(&cmd, "\x89\x21\x06\x11\xff\x98", 6, 3);
+    else if (c->delivery_system == SYS_DVBC_ANNEX_A)
+        cmd_init(&cmd, "\x89\x21\x06\x11\x89\xf0", 6, 3);
+    else if (c->delivery_system == SYS_DVBT2)
+        cmd_init(&cmd, "\x89\x21\x06\x11\x89\x20", 6, 3);
+    ret = si2168_cmd_execute(client, &cmd);
+    if (ret)
+        goto err;
 
     if (c->delivery_system == SYS_DVBT2) {
         /* select PLP */
@@ -480,9 +480,9 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
         goto err;
 
     cmd_init(&cmd, "\x14\x00\x08\x10\xd7\x05", 6, 4);
-    //cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
-    cmd.args[4] = dev->ts_clock_inv ? 0xd7 : 0xcf;
-    cmd.args[5] = dev->ts_clock_inv ? 0x05 : 0x33;
+    cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
+//     cmd.args[4] = dev->ts_clock_inv ? 0xd7 : 0xcf;
+//     cmd.args[5] = dev->ts_clock_inv ? 0x05 : 0x33;
     ret = si2168_cmd_execute(client, &cmd);
     if (ret)
         goto err;

Zeilen mit "-" kommen raus, die mit "+" rein.

Zeilennummern stehen zwischen den "@@" und der Dateiname ist ganz oben (das "a" und "b" sind nur Platzhalter für das "media")

In unserem Fall hier müssen aber nur die "//" verändert werden, die aus der Zeile ein Kommentar machen.

Das ist nicht von mir und war so im Code drin!

Die zweite Stelle wurde über die Jahre auch verdächtig oft hin und her geändert:

2015
    memcpy(cmd.args, "\x14\x00\x08\x10\xd7\x05", 6);    0xd7    0x05
    cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;             0x15
?
    memcpy(cmd.args, "\x14\x00\x08\x10\xcf\x33", 6);    0xcf    0x33
    // ohne!
2017
    memcpy(cmd.args, "\x14\x00\x08\x10\xcf\x33", 6);    0xcf    0x33
    cmd.args[4] = (dev->ts_mode==3)?0xd7:0xcf;          0xd7
    cmd.args[5] = (dev->ts_mode==3)?0x05:0x33;                  0x05
2018
    memcpy(cmd.args, "\x14\x00\x08\x10\xdf\x17", 6);    0xdf    0x17
    cmd.args[4] = dev->ts_clock_inv ? 0xdf : 0xcf;      0xcf
    cmd.args[5] = dev->ts_clock_inv ? 0x17 : 0x33;              0x33
?
    cmd_init(&cmd, "\x14\x00\x08\x10\xd7\x05", 6, 4);   0xd7    0x05
    cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;             0x15
2020
    cmd_init(&cmd, "\x14\x00\x08\x10\xd7\x05", 6, 4);   0xd7    0x05
    //cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
    cmd.args[4] = dev->ts_clock_inv ? 0xd7 : 0xcf;      0xcf
    cmd.args[5] = dev->ts_clock_inv ? 0x05 : 0x33;              0x33

Und das sind nur die Änderungen, die ich beim schnellen durchblättern gesehen habe!

Eine Frage noch:

Wird beim ARD-Transponder ein "lock" angezeigt?

(Beim ZDF müsste das der Fall sein, sonst hätten man kein Signal.)

Zitat von fhg

Gibt es auch etwas empfehlenswertes als PCI-Lösung?

Hatte nicht auch eine PCIe vierfach DVB-C/T Karte, sogar mit Treiber im Kernel?

Beim si2168-Treiber wurde zwar einiges geändert (unter anderem wurde die Funktion zu setzen der Register umbenannt) die für den Empfang relevanten Änderungen scheinen aber recht überschaubar zu sein.

Die ganzen Empfangspatches machen immer nur Änderungen an der zweiten Stelle.

Mal hin, mal zurück, mal in Abhängigkeit von irgendwas.

Nach dem Patch sollte diese Stelle aber funktionell wie 2016 sein, wenn ich nichts übersehen habe.

Zitat von wirbel

unsigned = 4byte.

Stimmt natürlich.

Dann hätte es dem Programmierer also eigentlich auffallen müssen.

(Ich persönlich vermeide diese Typen nach Möglichkeit, da ich mir das nie merken kann.

Das sind wohl Nebenwirkungen, wenn man zu viel mit 8-Bit µC rum spielt . )

dev_dbg() ist aber nur so etwas ähnliches wie printf(), damit schreibt mal Meldungen ins syslog.

Im dümmsten Fall steht da dann halt Schrott drin.

Im Normalfall macht dev_dbg() auch gar nichts, man erst debugging aktivieren.

Eine Problem dürfte das also trotzdem nicht sein.

Die Werte mit Antennenverstärker sehen eigentlich auch gar nicht schlecht aus.

-62 dBm entsprechen (+ 108,75) ca. 50 dBµV und man braucht bei DVB-T2 wohl mehr als 39 dBµV.

Von daher sollte es eigentlich passen.

Auch sind die Werte bei Ubuntu 16 und 22 identisch, das sieht eigentlich auch gut aus.

Ich würde da noch immer tippen, dass da eine geänderte Einstellung am Frontend das Problem ist.

Das blöde ohne Datenblatt ist, dass man bloß raten kann, welche.

Ausserdem gab es eine Haufen Änderungen an dem Frontend-Treiber, da es anscheinend auch mehrere Versionen des ICs mit unterschiedlicher Firmware gibt. Da das nicht reicht gibt es eine TBS6205 und eine TBS6205SE.

Bei TBS sollten die das aber eigentlich recht schnell raus finden können, zumindest sollten sie die nötigen Daten dazu haben. Da dvblast zeigt, dass da wirklich übel was schief läuft, müsste der Fehler eigentlich recht gut einzugrenzen sein.

Wenn da nichts kommt, kann ich ja noch mal versuchen, ein diff der Treiberdatei zu machen versuchen an Einstellungen zurück zu nehmen, was möglich ist.

Die yaVDR-Pakete müssten sich größtenteils auch auf Debian bauen lassen, jetzt wo beide auf systemd setzen.

Ich verwende selber einen bunten Mix aus Debian-, etobi- und selbst gebauten yaVDR-Paketen auf einem Debian-System.

Das ist aber alles noch älter (sysv-init) und das einzelne bauen der yaVDR-Pakete per Hand ist recht mühsam gewesen.

Erstaunlicherweise ist aber keine Nacharbeit an den Source-Paketen selber notwendig gewesen, ich konnte die einfach so bauen.

Gibt es eigentlich so etwas wie launchpad auch für Debian? Auf die Schnelle habe ich da nichts gefunden.

Oder eine einfache Möglichkeit den Paketbau irgendwie zu automatisieren?Wenn es nicht zu viel Aufwand macht, könnte man sowas ja mal aufsetzen und schauen, was raus kommt.

Die Warnungen sehen mir noch immer harmlos aus.

- [-Wunused-...] bedeutet nur, dass eine Variable/Funktion/Ergebnis existiert, die/das nicht genutzt wird.

- [-Wswitch] sinngemäß wie oben.

- [-Wimplicit-fallthrough=] an sich harmlos (allerdings kein guter Stiel).

- [-Wformat=] 'unsigned int' und '__u64' sollten auf einem 64-bit-System identisch sein.

- [-Wint-conversion] und [-Wpointer-to-int-cast] sinngemäß wie oben.

- [-Wmisleading-indentation] ist nur eine falsche Einrückung.

- [-Wvla] variable length array sind AFAIK zulässig, da ISO C99(?) Standard.

und dann ist nicht mehr viel übrig und das auch nicht mehr im Tunertreiber deiner Karte.

Die Skipping BTF generation for... haben wohl irgendwas mit der Treibersignierung zu tun.

Das hatte ich zwar noch nicht, wird aber nur bei einem Kernel, der signierte Module verlangt, Probleme bereiten.

Im Fehlerfall müsste das auch das laden der neuen Module ganz unterbinden, ist also auch eher auszuschliessen.

Die dvblast Ausgaben sehen beim ZDF aber auch miserabel aus:

warning: no lock, tuning again sollte eigentlich nicht auftreten.

Bei der ARD scheint es so schlecht zu sein, dass es nicht mal für einen LOCK reicht.

Ich würde mal behaupten, dass mit dem Empfang generell was richtig im Argen liegt. (Signal zu schwach/stark).

Zitat von fhg

Bei ZDF gibt's STR, CNR, BER, bei ARD nur STR

Und wie sehen die Werte aus?

Am besten, zum Vergleich auch noch die Alten (Ubuntu 16.x).

Zitat von fhg

Bestünde rein theoretisch die Möglichkeit, den Treiber aus meiner funktionierenden 16.04-Installation "herauszuoperieren" und in der 22.04-Installationn einzubauen?

Nein, die Module sind immer nur mit dem Kernel zu gebrauchen, für den sie gebaut wurden.

Man könnte aber die Änderungen am Tuner-Treiber rückgängig machen und so quasi den alten Tuner-Treiber neu bauen. Der Rest vom Treiber-Paket sollte nichts mit dem Empfang zu tun haben und da ist eindeutig das Problem.

Ich würde aber erstmal die Antennen-Situation überprüfen/verbessern.

Zitat von kamel5

Wenn man lokal mit vlc eine laufende VDR-Aufnahme abspielt, wird das Ende der Aufnahme solange man noch nicht am Ende mit der Wiedergabe angekommen ist, nicht aktualisiert.

Mit VLC klappt das bei mir auch über samba.

Es liegt also wohl am Xine-Player.

In dem Link ist noch ein Link auf Google Maps Overlay, das scheint aktueller zu sein.

Zumindest entspricht das in etwas der aktuellen Empfangssituation, nach der Satellitenumstellung.

Hier in der Ecke (Rheinebene Südhessen/Nordbaden/Pfalz), gibt es einige Erfolgsmeldungen.

Empfang sollte, zumindest im Bereich der Rheinebene auch Richtung Schweiz gehen. Je weiter westlicher, desto besser ist es wohl.

Auf dieser Seite gibt es einen Link zu einer Google Mapsseite, mit Empfangsdaten von Nutzern.

Grob gepeilt, würde ich sagen, dass es in Basel ähnlich wie hier HD, F, ... bzw. Münster aussieht.

NRW ist halt recht "breit", da musst Du selber mal schauen.

Zitat von nobanzai

Was nicht funktioniert sind VLC & Co, wenn ich diese von den per NFS oder unter Windows per SMB auf die o.a. Verzeichnisse zum Abspielen zugreifen lasse, während eine Aufnahme noch läuft. In dem Fall bekommen VLC & Co die Dateigröße in dem Moment, in dem sie die Datei öffnen. Danach wird die Dateigröße nie mehr aktualisiert, was dazu führt, dass VLC & Co mit dem Abspielen aufhören, wenn sie an dem anfangs erkannten Dateiende angekommen sind - obwohl die Aufnahme mittlerweile viel weiter, und die Datei viel größer ist.

Das kann ich so auch mit Xine unter Linux bestätigen (samba share).

Inzwischen bin ich aber am Überlegen, ob es überhaupt was mit dem Netzwerk/samba zu tun hat, oder ob es am Player liegt.

Leider kann ich das nicht direkt testen, da ich auf dem VDR-Rechner kein X usw. habe.

Mal mit apt-get --no-install-recommends versucht?

Die YaVDR-Pakete ließen sich bislang meist problemlos auch unter Debian bauen und dann einsetzen.

Ich habe das selber mal so gemacht, das ist aber schon etwas her.

Zur Frage, welche Pakete man aktuell für welches Debian versuchen sollte, müsste sich also mal jemand anderes äußern.

Genau wie zu der Frage, wie man das am besten automatisiert, per Hand runter laden und bauen war ein ziemlichen gefummel.

Das kuriose ist, finde ich, dass es so teilweise funktioniert.

Wenn die Änderungen der Datei gar nicht ankommen würden, wäre das verständlicher.

Aber man bekommt bei jedem Öffnen ja anscheinend zuverlässig den aktuellen Stand, der aber nicht aktualisiert wird. Irgendwie ist diese Verhalten schon merkwürdig.

Um das zu testen sollte es auch der Hauppauge-Empfänger tun.

Ich bin aber eher den umgekehrten Weg gegangen und bediene eigentlich nur noch den VDR, weil mich die eher schlechten IR-Empfänger in den meisten anderen Geräten ziemlich nerven.

Eventuell lohnt es mal den Xine-Player xine xvdr://localhost zu versuchen, der weird besser betreut.

Ich kann das Problem mit dem Xine-Player] aber teilweise bestätigen.

Das meiste geht einwandfrei, aber alles, was mit dem ZDF zu tun hat, hat merkwürdige Bildstörungen.

Allerdings ist mein Player auch nicht mehr der Neueste.

Die Warnungen sehen mir eher harmlos aus, zumal die meisten einen Tuner betreffen, der nicht auf dieser Karte ist.

ZDF HD;ZDFmobil:586000:B8D0G19128S1T16Y0P0:T:27500:2110=36:0;2120=deu@122,2121=mis@122,2122=mul@122:2130;2131=deu:0:2001:8468:515:0

-> dvblast -f 586000000 -s 27500000 -b 8

Eigentlich sollte das so passen.

Evtl. ist bei der Frequenz (erster Wert) ein 000 zu viel oder zu wenig drin.

Zitat von man vdr.5

The transponder frequency (as an integer). For DVB-C and DVB-T it can be given either in MHz, kHz or Hz

Schade.

An einer Lösung wäre ich nämlich auch interessiert.

In der Manpage von mount.cifs habe ich auch nichts brauchbare gesehen.

Leider gibt es anscheinend viele Fälle, wo irgendwas bei SAMBA nicht aktualisiert. Da sieht man den Wald lauter vor Bäumen nicht.

Die Belegung der 2,5mm "Hauppauge-IR-Stecker" ist immer:

Spitze: +5V

Ring: Signal

Basis: GND

Die originalen Empfänger taugen aber nicht besonders viel, die sind ziemlich unempfindlich.

Die TSOP 312xx sind um Welten besser.