Full-TS Mod für FF-Karten

jowi24 · 31. Januar 2009

Zitat

Originally posted by UFO
Schau mal im BIOS, wie der PCI-Latency-Timer eingestellt ist.
Der Wert 32 erscheint mir niedrig. Versuche mal 64 oder 128.

Der Wert war auf 32, eine Erhöhung auf 128 hat leider auch keine Verbesserung erzielt.

Ich frage mich, ob das Problem nicht auch bei "low-level" Tools, wie mode2 auftreten sollte. Der Strom an pulses und spaces der dort geliefert wird, erscheint mir ziemlich konstant, auch wenn nebenbei der VDR läuft.

UFO · 1. Februar 2009

Zitat

Original von jowi24

Der Wert war auf 32, eine Erhöhung auf 128 hat leider auch keine Verbesserung erzielt.

War auch nur eine schwache Hoffnung.

Diese Einstellungen wirken sich eigentlich erst aus, wenn die Last auf dem PCI-Bus so hoch ist, daß die Bandbreite zwischen den Komponenten aufgeteilt werden muß. Eine einzige DVB-Karte erzeugt keine nennenswerte Last auf dem PCI-Bus...

Zitat

Ich frage mich, ob das Problem nicht auch bei "low-level" Tools, wie mode2 auftreten sollte. Der Strom an pulses und spaces der dort geliefert wird, erscheint mir ziemlich konstant, auch wenn nebenbei der VDR läuft.

Eigentlich müßte das Problem damit ebenso auftreten. Irgendetwas müßte sich ändern, wenn VDR läuft.

Sorry, ich kann Dir bzgl. LIRC nicht weiterhelfen, denn LIRC habe ich schon vor mehr als 6 Jahren über Bord geworfen.

CU
Oliver

jowi24 · 1. Februar 2009

Zitat

Original von UFO
Sorry, ich kann Dir bzgl. LIRC nicht weiterhelfen, denn LIRC habe ich schon vor mehr als 6 Jahren über Bord geworfen.

Danke für den Hinweis Ich habe mir grade das remote-Plugin installiert, den IR-Sensor direkt an die DVB-Karte angeschlossen und eine alte RC5-kompatible FB aus dem Schrank gekramt. Das ist das erste Mal, dass ich den full-ts-gemoddeten VDR richtig mit FB nutzen kann.

Was ein Workaround...

Marcus 2208 · 1. Februar 2009

Könnte es sein dass die FF im FullTS-Mode einen anderen (oder sogar einen zweiten) IRQ benutzt als normal, und dass dieser dann zufällig identisch mit dem COM1 (standardmässig IRQ4) ist? Dann würde, falls vorhanden, der COM2 (IRQ3) für LIRC besser funktionieren.

Poste doch mal bitte die Ausgabe von

Code

cat /proc/interrupts

mit und ohne FullTS. Das könnte für andere hilfreich sein.

Grüße
Marcus

EDIT: Sorry, hab grad gemerkt dass ich zu spät bin. Also vergesst es...

jowi24 · 1. Februar 2009

Zitat

Original von Marcus 2208
Könnte es sein dass die FF im FullTS-Mode einen anderen (oder sogar einen zweiten) IRQ benutzt als normal, und dass dieser dann zufällig identisch mit dem COM1 (standardmässig IRQ4) ist? Dann würde, falls vorhanden, der COM2 (IRQ3) für LIRC besser funktionieren.

Die DVB-Karte liegt auf IRQ 11, COM1 auf IRQ 4. Sowohl mit als auch ohne Full-TS. Trotzdem vielen Dank für den Hinweis.

UFO · 1. Februar 2009

Zitat

Original von jowi24

Danke für den Hinweis Ich habe mir grade das remote-Plugin installiert, den IR-Sensor direkt an die DVB-Karte angeschlossen und eine alte RC5-kompatible FB aus dem Schrank gekramt. Das ist das erste Mal, dass ich den full-ts-gemoddeten VDR richtig mit FB nutzen kann.

Was ein Workaround...

Wobei sich LIRC und FullTS-Mod sicher nicht ausschließen (sonst würden sich viel mehr Leute beschweren).
Da muß bei Dir noch irgendein unbekannter Faktor mitspielen. Ich denke, Du hättest das gleiche Problem bekommen, wenn Du eine gewöhnliche Budget-Karte eingebaut hättest...

CU
Oliver

e9hack · 1. Februar 2009

Bei aktiven Full-TS-Mod wird alle 16KByte übertragene Daten ein Interrupt ausgelöst, der wiederum ein Tasklet aktiviert, das einen Software-Demuxer startet. Der SW-Demuxer sperrt alle Interrupts und scannt dann die Packete. Kann es sein, daß die CPU so schwachbrüstig ist, daß der Scan zu lange dauert und die LIRC-Interrupts dadurch blockiert werden?

Gruß
e9hack

UFO · 2. Februar 2009

Zitat

Original von e9hack
Bei aktiven Full-TS-Mod wird alle 16KByte übertragene Daten ein Interrupt ausgelöst, der wiederum ein Tasklet aktiviert, das einen Software-Demuxer startet. Der SW-Demuxer sperrt alle Interrupts und scannt dann die Packete. Kann es sein, daß die CPU so schwachbrüstig ist, daß der Scan zu lange dauert und die LIRC-Interrupts dadurch blockiert werden?

Dies ist erst seit Changeset http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833 so.
War imho keine gute Idee!

CU
Oliver

e9hack · 2. Februar 2009

Zitat

Original von UFO

Dies ist erst seit Changeset http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833 so.
War imho keine gute Idee!

Wenn das wirklich die Ursache ist, könnte av7110 die Daten in TS-Packeten an den SW-Demuxer weiterreichen. Dann werden die Interrupts nicht so lange gesperrt.

Gruß
e9hack

UFO · 2. Februar 2009

Zitat

Original von e9hack

Wenn das wirklich die Ursache ist, könnte av7110 die Daten in TS-Packeten an den SW-Demuxer weiterreichen. Dann werden die Interrupts nicht so lange gesperrt.

Sehe ich nicht so. Dieser Changeset sollte rückgängig gemacht werden.

Das ganze war nicht ohne Grund so geschrieben, wie es war: Man verarbeitet keine Datenpuffer mit gesperrten Interrupts.
Und av7110 und budget*-Treiber verwenden Tasklets, damit man die Interrupts eben nicht sperren muß.

Damit soll sich aber beschäftigen, wer will. Ich habe keine Lust mehr, mit den v4l-Jungs über Grundlagen der Programmierung zu diskutieren, um zu verhindern, daß irgendetwas kaputt gemacht wird. Ich bin es leid.

CU
Oliver

jowi24 · 2. Februar 2009

Zitat

Original von UFO
Wobei sich LIRC und FullTS-Mod sicher nicht ausschließen (sonst würden sich viel mehr Leute beschweren).
Da muß bei Dir noch irgendein unbekannter Faktor mitspielen. Ich denke, Du hättest das gleiche Problem bekommen, wenn Du eine gewöhnliche Budget-Karte eingebaut hättest...

Sehe ich auch so. Wenn ich mal eine Budget in die Hand kriege, probiere ich es auf jeden Fall mal aus, rein aus Neugierde...

Marcus 2208 · 2. Februar 2009

Zitat

Damit soll sich aber beschäftigen, wer will. Ich habe keine Lust mehr, mit den v4l-Jungs über Grundlagen der Programmierung zu diskutieren, um zu verhindern, daß irgendetwas kaputt gemacht wird. Ich bin es leid.

Naja, sollte aber auf jeden Fall in Ordnung gebracht werden. Der FullTS-Mod ist eine geniale Sache, schade wenn´s durch sowas kaputt gemacht würde!

jowi24 · 2. Februar 2009

Zitat

Original von Marcus 2208

Naja, sollte aber auf jeden Fall in Ordnung gebracht werden. Der FullTS-Mod ist eine geniale Sache, schade wenn´s durch sowas kaputt gemacht würde!

Blöde Frage: Gibt es eine Version mit Full-TS und ohne besagte Änderung, die ich mal ausprobieren könnte? Nur um zu verifizieren, ob es da einen Zusammenhang gibt, oder nicht?

Diese hier, beispielsweise: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod ?

M-Reimer · 2. Februar 2009

Zitat

Original von UFO
Sehe ich nicht so. Dieser Changeset sollte rückgängig gemacht werden.

Das ganze war nicht ohne Grund so geschrieben, wie es war: Man verarbeitet keine Datenpuffer mit gesperrten Interrupts.
Und av7110 und budget*-Treiber verwenden Tasklets, damit man die Interrupts eben nicht sperren muß.

Damit soll sich aber beschäftigen, wer will. Ich habe keine Lust mehr, mit den v4l-Jungs über Grundlagen der Programmierung zu diskutieren, um zu verhindern, daß irgendetwas kaputt gemacht wird. Ich bin es leid.

Hat schon jemand diese Änderung als Ursache des Problems ausgemacht?

Warum wurde die Änderung überhaupt durchgeführt?

Wer kann das Problem mit LIRC mal bei denen bekannt machen?

jowi24 · 2. Februar 2009

Zitat

Original von Mreimer
Hat schon jemand diese Änderung als Ursache des Problems ausgemacht?

Warum wurde die Änderung überhaupt durchgeführt?

Wer kann das Problem mit LIRC mal bei denen bekannt machen?

Die Änderung war im September, wie aus obigem Link auf das Repository ersichtlich. Noch ist der Zusammenhang meines Erachtens aber nicht bewiesen.

UFO · 2. Februar 2009

Zitat

Original von jowi24

Blöde Frage: Gibt es eine Version mit Full-TS und ohne besagte Änderung, die ich mal ausprobieren könnte? Nur um zu verifizieren, ob es da einen Zusammenhang gibt, oder nicht?

Diese hier, beispielsweise: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod ?

In diesem Repository ist der fragliche Changeset nicht enthalten.

Habe gerade nachgeschaut:
Der Changeset ist seit 2.6.27 im Kernel. Ich halte es für wahrscheinlich, daß die Probleme von oben durch diesen Patch verursacht werden. Wer also Interrupt-Probleme hat, sollte diesen Changeset probehalber rückgängig machen.

Ohne den Hinweis von e9hack wäre ich niemals darauf gekommen. Ich wußte gar nicht, was die da eingebaut haben. Danke nochmal!

CU
Oliver

e9hack · 2. Februar 2009

Hi,

ich habe in dvb_dmx_swfilter_packets() zusätzlichen Debug-Code eingefügt, der alle 10000 Aufrufe für die nächsten 20 Aufrufe die Laufzeit innerhalb des Spinlocks bei gesperrten Interrupts mißt:

Diff

diff -r 1dce9d4e2179 linux/drivers/media/dvb/dvb-core/dvb_demux.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_demux.c      Sun Feb 01 11:40:27 2009 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.c      Mon Feb 02 21:12:49 2009 +0100
@@ -400,16 +400,33 @@ void dvb_dmx_swfilter_packets(struct dvb
                              size_t count)
 {
        unsigned long flags;
+       size_t _count = count;
+       struct timeval tv1, tv2;
+       long delta = 0;
+       static long c = 0;
+       static long cc = 0;


        spin_lock_irqsave(&demux->lock, flags);
-
+       if (c < 20)
+               do_gettimeofday(&tv1);
+
+       cc += count;
        while (count--) {
                if (buf[0] == 0x47)
                        dvb_dmx_swfilter_packet(demux, buf);
                buf += 188;
        }


+       if (c < 20) {
+               do_gettimeofday(&tv2);
+               delta = 1000000 * (tv2.tv_sec - tv1.tv_sec) + tv2.tv_usec - tv1.tv_usec;
+       }
+       c++;
+       if (c >= 10000)
+               c = 0;
        spin_unlock_irqrestore(&demux->lock, flags);
+       if (delta)
+               printk("(%s:%d) count=%ld(%ld) t=%ldus\n", __FILE__, __LINE__, _count, cc, delta);
 }


 EXPORT_SYMBOL(dvb_dmx_swfilter_packets);

Alles anzeigen

Bei mir läuft das ganze mit einer Budget-Karte. Die Ergebnisse sollten aber mit dem Full-TS-Mod vergleichbar sein. Die CPU läuft aktuell mit 1GHz:

Code

Feb  2 21:07:32 linux-qgjx kernel: [ 2074.141310] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1668717) t=4us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.143882] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1668721) t=7us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.146497] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1668725) t=12us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.147611] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=349(1669074) t=100us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.149131] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669078) t=5us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.151675] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669082) t=5us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.153584] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=3(1669085) t=4us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.156180] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669089) t=5us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.158844] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669093) t=5us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.161382] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=349(1669442) t=98us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.161528] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669446) t=19us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.164082] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669450) t=8us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.166732] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669454) t=5us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.169280] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669458) t=5us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.171900] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669462) t=15us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.173527] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=2(1669464) t=12us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.175092] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=348(1669812) t=100us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.175457] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669816) t=8us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.177812] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=5(1669821) t=14us
Feb  2 21:07:32 linux-qgjx kernel: [ 2074.180431] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(1669825) t=9us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.493277] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2216932) t=5us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.493946] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=1(2216933) t=7us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.496122] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2216937) t=5us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.498654] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2216941) t=8us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.501424] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2216945) t=14us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.503938] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2216949) t=9us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.505933] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=349(2217298) t=117us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.506490] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217302) t=5us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.509102] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217306) t=11us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.511634] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217310) t=9us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.513367] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=2(2217312) t=7us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.515651] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217316) t=7us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.517947] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217320) t=15us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.519666] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=348(2217668) t=108us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.520208] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217672) t=6us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.522754] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217676) t=13us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.525394] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217680) t=12us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.528131] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217684) t=7us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.530682] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217688) t=16us
Feb  2 21:07:52 linux-qgjx kernel: [ 2094.533297] (/usr/src/v4l-dvb/v4l/dvb_demux.c:429) count=4(2217692) t=10us

Alles anzeigen

Eigentlich hätte ich ja erwartet, daß ich Aufrufe für ca. 87 TS-Packete sehe, was einem Interrupt/Tasklet alle 16kByte entspricht. Die 349 TS-Packete entsprechenaber einer Blockgröße von 64kByte. Momentan verstehe ich nicht, warum immer ca. 6 kurze und danach wieder ein langes Packet kommt. Wenn ich die CPU-Frequenz auf 1,8GHz erhöhe werden die Laufzeiten entsprechend kürzer. Mit der Interruptsperre von ca. 100µs funktioniert Lirc über den COM-Port mit einer RC5-Fernbedienung problemlos. Bei RC5 ist die kürzeste Pulszeit ca. 890µs. Lirc scheint da tollerant zu sein. Andere Protokolle haben kürzere mögliche Pulszeiten. Bei NEC-Protokoll sind das z.B. 560µs. Wenn die CPU etwas lahm ist und die Sperrzeiten länger werden, kann Lirc Probleme bekommen.

Gruß
e9hack

jowi24 · 2. Februar 2009

Kurze Rückmeldung von meiner Seite: Mit v4l-dvb-av7110-full-ts-mod-adf34f76ab7c funktioniert alles einwandfrei: full_ts + lirc.

UFO · 3. Februar 2009

Zitat

Original von e9hack
Hi,

ich habe in dvb_dmx_swfilter_packets() zusätzlichen Debug-Code eingefügt, der alle 10000 Aufrufe für die nächsten 20 Aufrufe die Laufzeit innerhalb des Spinlocks bei gesperrten Interrupts mißt:
...
Eigentlich hätte ich ja erwartet, daß ich Aufrufe für ca. 87 TS-Packete sehe, was einem Interrupt/Tasklet alle 16kByte entspricht. Die 349 TS-Packete entsprechenaber einer Blockgröße von 64kByte. Momentan verstehe ich nicht, warum immer ca. 6 kurze und danach wieder ein langes Packet kommt. Wenn ich die CPU-Frequenz auf 1,8GHz erhöhe werden die Laufzeiten entsprechend kürzer. Mit der Interruptsperre von ca. 100µs funktioniert Lirc über den COM-Port mit einer RC5-Fernbedienung problemlos. Bei RC5 ist die kürzeste Pulszeit ca. 890µs. Lirc scheint da tollerant zu sein. Andere Protokolle haben kürzere mögliche Pulszeiten. Bei NEC-Protokoll sind das z.B. 560µs. Wenn die CPU etwas lahm ist und die Sperrzeiten länger werden, kann Lirc Probleme bekommen.

Ich denke, man muß höllisch aufpassen, daß man durch eine Messung nicht die Ergebnisse verfälscht.
Habe hier folgendes eingebaut, um einfach nur die Größenverteilung zu ermitteln:

Diff

diff -r 1930f80b6970 linux/drivers/media/dvb/dvb-core/dvb_demux.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_demux.c      Sun Dec 14 15:38:29 2008 +0100
+++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.c      Tue Feb 03 00:51:45 2009 +0100
@@ -31,6 +31,9 @@
 #include <asm/uaccess.h>


 #include "dvb_demux.h"
+
+static ulong ts_cnt[100];
+module_param_array(ts_cnt, ulong, NULL, 0644);


 #define NOBUFS
 /*
@@ -400,6 +403,11 @@ void dvb_dmx_swfilter_packets(struct dvb
                              size_t count)
 {
        unsigned long flags;
+       unsigned idx = count / 10;
+
+       if (idx > 99)
+               idx = 99;
+       ts_cnt[idx]++;


        spin_lock_irqsave(&demux->lock, flags);

Alles anzeigen

Test mit Full-TS FF-Karte. Nach einiger Zeit ein "cat /sys/module/dvb_core/parameters/ts_cnt" liefert:

Code

10503,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,10502,0,20710,295,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

Ich finde die Verteilung nicht ungewöhnlich. Die "kleinen" Puffer stammen daher, daß im Tasklet bei einem Wrap des Puffers die Demuxer-Funktion zweimal aufgerufen wird.

CU
Oliver

UFO · 3. Februar 2009

Zitat

Original von jowi24
Kurze Rückmeldung von meiner Seite: Mit v4l-dvb-av7110-full-ts-mod-adf34f76ab7c funktioniert alles einwandfrei: full_ts + lirc.

Sag ich doch.

Um ganz sicher zu sein, könntest Du im fehlerhaften Treiber einmal genau diesen Patch herausnehmen:
Changeset http://linuxtv.org/hg/v4l-dvb/raw-rev/aa3e5cc1d833 (einfach mit "patch -p1 -R" rückgängig machen)

CU
Oliver

Full-TS Mod für FF-Karten

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema