Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Themen - mv

Seiten: [1]
1
Software / DVB-T2 mit tzap in Rostock
« am: Oktober 03, 2017, 10:59:03 Vormittag »
Hallo,

da ich gerne Script-gesteuert aufnehme (und dies mit dem streamingserver nicht so einfach zu machen scheint), würde ich gerne DVB-T2 mit tzap aufnehmen.

In Berlin ging dies auch problemlos: w_scan -X hat mir eine channels.conf generiert, die mit tzap funktioniert hat.

Nach dem Umzug nach Rostock gibt es aber Probleme:
Code: [Auswählen]
/opt/bin/mediaclient --blindscan /dev/dvb/adapter0/frontend0gibt mir 6 Kanäle aus. Inzwischen weiß ich, dass 3 davon Öffentlich-Rechtliche Transponder sind (s. unten).

w_scan findet aber nur die 3 Kommerziellen (die natürlich nicht gehen) und einen der 3 Öffentlich-Rechtlichen. (Sicherheitshalber habe ich auch mit der aktuellsten w_scan-Version 20170107 getestet).

Genauer ist die Ausgabe bei einem der beiden nicht-gefundenen Kanäle im 1. Pass
Code: [Auswählen]
594000: (time: 00:38.803)         signal ok:    QAM_64   f = 594000 kHz I999B8C999D999T999G999Y999 (0:0:0)
        QAM_64   f = 594000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:2562)
        QAM_64   f = 594000 kHz I999B8C999D999T999G999Y999 (0:0:2562) : updating network_id -> (0:12298:2562)
        updating transponder:
           (QAM_64   f = 594000 kHz I999B8C999D999T999G999Y999 (0:12298:2562)) 0x0000
        to (QAM_AUTO f = 594000 kHz I999B8C999D0T16G19128Y0P1 (8468:12298:2562)) 0x4004aber abscheinend wird nichts gefunden, was ausgegeben werden kann. Bei der anderen Frequnz kommt sogar im 2. Pass nur ein
Code: [Auswählen]
tune to: QAM_AUTO f = 746000 kHz I999B8C999D0T16G19128Y0P1 (8468:12306:4610) (time: 09:33.866)
----------no signal----------
tune to: QAM_AUTO f = 746000 kHz I999B8C999D0T999G999Y0P1 (8468:12306:4610) (time: 09:43.336)  (no signal)
----------no signal----------Bei der 3. Öffentlich-Rechtlichen Frequenz, die w_scan findet, enthält die generierte channels.conf u.a. die Werte
Code: [Auswählen]
TRANSMISSION_MODE_16K:GUARD_INTERVAL_19_128die tzap nicht kennt. Es funktioniert aber, wenn ich diese Werte jeweils von Hand auf
Code: [Auswählen]
TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTOumändere.

Mit den beiden problematischen Frequenzen habe ich ein init-File für scan-dvb (aus linutv-dvb-apps, dem gleichen Paket aus dem auch tzap stammt) manuell gebastelt: Bis auf die Frequenz habe ich alle anderen Werte auf "..._AUTO" gestellt (ähnlich wie oben).

Ergebnis: scan-dvb findet die Sender (daher weiß ich, dass es sich um Öffentlich-Rechtliche handelt).

Aber: Aufnehmen mit tzap erzeugt sehr kleine Dateien, die ausschließlich den Ton enthalten.
Auch Umändern von ..._AUTO auf verschiedene andere Werte brachte bislang immer das gleiche Ergebnis.

Am Empfang liegt es aber nicht: Der sundtek streamingserver findet alle Öffentlich-Rechtlichen und kann sie auch anzeigen.

Ist es sinnvoll, außer ..._AUTO noch verschiedenste andere Kombinationen systematisch durchzuprobieren, oder kann es sein, dass es Daten gibt die tzap nicht einstellt, aber der streamingserver? Kann ich diese Daten ev. manuell mit mediaclient einstellen?

Falls es hilft: Bei einem der beiden problematischen Frequenzen erhalte ich nach
Code: [Auswählen]
/opt/bin/mediaclient -m DVBT2 -f 5940
/opt/bin/mediaclient --readsignal=20 -d /dev/dvb/adapter0/frontend000000 -b 8die Ausgabe
Code: [Auswählen]
SIGNAL: [.............................    ] ( 88%) BER:      0 CNR: 31.50 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [............................     ] ( 86%) BER:      0 CNR: 31.50 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [............................     ] ( 86%) BER:      0 CNR: 31.20 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [............................     ] ( 86%) BER:      0 CNR: 31.20 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [............................     ] ( 86%) BER:      0 CNR: 31.20 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      2 CNR: 31.50 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      2 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      2 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      2 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      0 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      0 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      0 CNR: 32.00 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      0 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      1 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      1 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      1 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      1 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      1 CNR: 32.00 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      2 CNR: 31.70 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhz
SIGNAL: [.............................    ] ( 88%) BER:      2 CNR: 32.20 FREQ: 594000000  Hz LOCKED: YES BW: 8 Mhzweiß aber nicht, ob/wie ich diese Ausgabe in ein channels.conf übersetzen kann.

2
Software / Wie DVB-T2 nutzen?
« am: Oktober 09, 2016, 08:53:48 Nachmittag »
Hallo,

wie kann man beim Sundtek MediaTV Pro III (DVB-C/T/T2, FM-Radio, AnalogTV)
DVB-T2 statt DVB-T benutzen?

Was ich gemacht habe:

mediaclient -DDVBT2  (statt -DDVBT)

und dann alles so versucht, wie bei DVB-T:
Aus http://linuxtv.org/hg/dvb-apps (zunächst mit einer deutlich älteren Version) das scan-dvb (später auch das alternative w_scan) und dann tzap.

Es scheint aber Nichts zu funktionieren:
scan-dvb und w_scan hatten zunächst nichts gefunden. Für scan-dvb hatte ich aber auch das selbe initial-tuning-data-file wie für DVB-T benutzt, weil ich nirgendwo ein anderes gefunden habe.

Irgendwann ging dann Beides, aber möglicherweise hatte sich der Stick wieder in den DVB-T-Modus zurückgesetzt, denn ich hatte i.W. die selbe Tabelle wie bei DVB-T erhalten.

Das macht bereits stutzig, denn angeblich sollen hier in Berlin derzeit nur 6 Kanäle über DVB-T2 verfügbar sein...

Mit tzap bekomme ich im DVB-T2-Modus keinen der gefundenen Kanäle; upgraden auf aktuelle mercurial-Version von tzap hat nicht viel geändert:

Code: [Auswählen]
$ tzap -o file -c /etc/channels-tzap.conf -- ZDF
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/etc/channels-tzap.conf'
tuning to 570000000 Hz
video pid 0x0221, audio pid 0x0222
status 00 | signal 386e | snr 386e | ber 00000000 | unc 00000000 |Nach Rückschalten mit mediaclient -DDVBT sind auch die Zahlen in der letzten Zeile anders:
Code: [Auswählen]
status 1f | signal ffff | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK
Braucht man ev. für DVB-T2 ganz andere Userspace-Programme? Welche?

Oder reicht da die Zimmerantenne vielleicht einfach nicht (obwohl ich ziemlich nahe am Zentrum bin und mit DVB-T ziemlich guten Empfang habe...)

3
Software / zsh completion und wrapper scripts
« am: Februar 20, 2016, 01:05:20 Nachmittag »
Für jeden, den es interessiert:

  • Es gibt eine zsh-completion für mediaclient im mv overlay für gentoo.
  • Ebenso gibt es dort ein Wrapper-Skript, das die -d-Option von mediaclient automatisch setzt.

Die Dateien sind vollkommen frei, dürfen also gerne (ggf. modifiziert) in andere Distributionen oder den Sundtek tarball aufgenommen werden. Man findet sie in

https://gitweb.gentoo.org/user/mv.git/tree/media-tv/sundtek-tv/files/

Anleitung:
  • Für zsh-completion: Einfach _mediaclient in irgendeinem Directory des $fpath der zsh ablegen (bei genoo ist dies per Default /usr/share/zsh/site-functions).
  • Das wrapper-Skript mediaclient.video einfach irgendwo in den $PATH kopieren und Symlinks von mediaclient.radio und mediaclient.dvb auf das Script machen (der Aufrufname entscheidet über das gewählte Device).
Die zsh-completion unterstützt auch die Wrapper-Skripte.

4
Sundtek MediaTV Pro / Probleme mit openat() bei 32bit (gelöst)
« am: Mai 28, 2014, 10:30:42 Vormittag »
Hallo,

ich bin auf ein seltsames Problem im Zusammenhang mit openat() gestoßen, das merkwürdigerweise nur bei den 32bit-Treibern auftritt, aber nicht bei den 64bit-Treibern. Das Problem wurde in https://forums.gentoo.org/viewtopic-t-991874.html beschrieben, aber ich fasse hier noch einmal zusammen.

Problembeschreibung: Mit tar-1.27.1 (bei tar-1.26 scheint eine andere Implementierung das Problem zu vermeiden, andere Versionen habe ich nicht getestet) entpacke man zweimal ein Archiv (mit relativen Pfaden) in das selbe Directory. Beim zweitenmal versucht tar, die Dateien nach "/" statt in das aktuelle Directory zu entpacken. Wenn man /etc/ld.so.preload entfernt, verschwindet das Problem, so dass die sundtek-Treiber zumindest implizit mitverantwortlich sind. Das Problem tritt nur bei 32bit, nicht aber bei 64bit auf. Bei 32bit tritt das Problem sowohl mit glibc-2.17 als auch mit glibc-2.19 auf.

Analyse: Obwohl tar-1.27.1 zwar eine Fallback-Implementation von openat() mitbringt, wird diese (zumindest auf meinem System) anscheinend nicht benutzt, sondern direkt die glibc-Funktion openat() aufgerufen. "strace" zeigt, dass openat() vom Sundtek-Treiber anscheinend (direkt oder indirekt) überladen wird, und dass sich der openat()-Bibliotheksaufruf von tar dadurch effektiv in folgende Aufrufe (auf dem 32Bit-System) übersetzt:
Code: [Auswählen]
openat(AT_FDCWD, "somedir/somefile", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0644) = -1 EEXIST (File exists)
readlink("/proc/self/fd/-100", 0xfbcf5293, 100) = -1 ENOENT (No such file or directory)
open("/somedir/somefile", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0644) = -1 ENOENT (No such file or directory)Auf dem 64bit-System ohne das Problem sieht die Übersetzung anders auf:
Code: [Auswählen]
openat(AT_FDCWD, "somedir/somefile", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0644) = -1 EEXIST (File exists)
unlinkat(AT_FDCWD, "somedir/somefile", 0) = 0
openat(AT_FDCWD, "somedir/somefile", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0644) = 4Anders als bei 32bit wird bei 64bit also weder der merkwürdige "readlink()"-Aufruf ausgeführt, noch wird ein open() mit vorgestelltem "/" aufgerufen.

Edit: Möglicherweise tritt das Problem erst mit neueren Versionen des Sundtek-Treibers auf; ich kann aber nicht mehr nachvollziehen, seit wann, und habe ältere Versionen jetzt auch nicht systematisch getestet.

5
Sundtek MediaTV Pro / Sporadisches "USB disconnect" bei Analog-TV
« am: Mai 18, 2014, 12:57:59 Nachmittag »
Hallo,

ich habe ein schwer reproduzierbares Problem, das aber doch alle paar Stunden bei Nutzung von Analog TV auftritt:

Der mplayer/mplayer2/mencoder bleibt "hängen" mit der Meldung
Code: [Auswählen]
v4l2: ioctl dequeue buffer failed: Success, idx = 0
v4l2: ioctl query buffer failed: Broken pipe, idx = 0Im mplayer werden dann die letzten beiden Bilder endlos wiederholt.

Neustart nach kurzer Pause funktioniert häufig, aber nicht immer: Manchmal kommen die selben Hänger nach 3-4 Sekunden nach Neustart wieder, manchmal auch sofort; falls ja, ist das minutenlang reproduzierbar, und selbst Neueinstecken des Sticks, ja sogar Abschalten des Stroms des Rechners ändert daran nichts. Merkwürdigerweise geht es nach etlichen Minuten dann meist aber doch wieder, und zwar für etliche Stunden zuverlässig, bis der Stick irgendwann wieder in diesen schlechten "Modus" fällt.

In den Logs sehe ich im günstigen Fall (falls es danach gleich wieder geht):
Code: [Auswählen]
[...] lange nichts [...]
12:24:09 18.05.14 [kernel] usb 3-7: USB disconnect, device number 9
12:24:10 18.05.14 [kernel] usb 3-7: new high-speed USB device number 10 using xhci_hcd
12:24:10 18.05.14 [mtp-probe] checking bus 3, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
12:24:10 18.05.14 [mtp-probe] bus: 3, device: 10 was not an MTP device_
12:24:11 18.05.14 [kernel] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input13
12:24:29 18.05.14 [kernel] usb 3-7: usbfs: process 1594 (mediasrv) did not claim interface 0 before useIm ungünstigen Fall sehe ich Kaskaden von solchen Meldungen:
Code: [Auswählen]
19:42:27 14.05.14 [kernel] usb 3-7: USB disconnect, device number 6
19:42:27 14.05.14 [kernel] usb 3-7: new high-speed USB device number 7 using xhci_hcd
19:42:27 14.05.14 [mtp-probe] checking bus 3, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
19:42:27 14.05.14 [mtp-probe] bus: 3, device: 7 was not an MTP device_
19:42:28 14.05.14 [kernel] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input11
19:42:47 14.05.14 [kernel] usb 3-7: usbfs: process 1643 (mediasrv) did not claim interface 0 before use
19:44:58 14.05.14 [kernel] usb 3-7: USB disconnect, device number 7
19:44:58 14.05.14 [kernel] usb 3-7: new high-speed USB device number 8 using xhci_hcd
19:44:59 14.05.14 [mtp-probe] checking bus 3, device 8: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
19:44:59 14.05.14 [mtp-probe] bus: 3, device: 8 was not an MTP device_
19:44:59 14.05.14 [kernel] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input12
19:45:18 14.05.14 [kernel] usb 3-7: usbfs: process 1643 (mediasrv) did not claim interface 0 before use
19:46:06 14.05.14 [kernel] usb 3-7: USB disconnect, device number 8
19:46:07 14.05.14 [kernel] usb 3-7: new high-speed USB device number 9 using xhci_hcd
19:46:07 14.05.14 [mtp-probe] checking bus 3, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
19:46:07 14.05.14 [mtp-probe] bus: 3, device: 9 was not an MTP device_Auffallend für mich ist in der "schlechten" Phase das systematische Durchlaufen der Device-Nummern.

mtp-probe scheint übrigens mit dem Problem nichts zu tun zu haben: Wenn der Stick seine schlechte "Phase" hatte, habe ich die entsprechende udev-Regel auch schon entfernt, ohne eine wesentliche Änderung zu erzielen.

Der Erstauslöser ist aus den Logs aber vermutlich nicht sichtbar, denn die "USB disconnect" Meldung sollte ja vermutlich nicht aus heiterem Himmel auftreten...

6
Sundtek MediaTV Pro / Fernbedienung unter Gentoo (gelöst)
« am: Mai 11, 2014, 06:56:51 Nachmittag »
Vielleicht ist das ein klassisches PEBCAK, aber ich bin unter Gentoo Linux nicht in der Lage, die Fernbedienung anzusprechen. Dazu muss man wissen, dass man unter Gentoo den Kernel selbst baut, und auch den lirc-Treiber selbst auswählen muss. Vielleicht fehlt also nur eine triviale Kernel-Option, oder ich habe lirc mit den falschen Treibern gebaut. (Vielleicht ist aber auch das ebuild buggy, das den Treiber installiert...)

Entsprechend http://support.sundtek.com/index.php?topic=46.0 habe ich meine Fernbedienung (#2) mit
Code: [Auswählen]
/opt/bin/mediaclient --updaterc=2 -d /dev/mediainput0 konfiguriert, aber ich fürchte, ich bin gar nicht so weit gekommen, dass das relevant wäre...

Was bislang funktioniert: TV einwandfrei, von der Fernbedienung scheint der Kernel gar nichts zu wissen: Keine logmeldung, kein /dev/lirc* wird generiert, /proc/bus/input/devices enthält nichts bzgl. sundtek (lsusb zeigt aber, dass der Stick da ist, und TV geht ja auch). Wenn nicht eine Fernbedienung mitgeliefert worden wäre, hätte ich vermutet, dass der Stick gar keine unterstützt...

Nachdem ich zunächst die grsecurity-Patches im Verdacht hatte, habe ich jetzt einen Vanilla-Kernel 3.14.3 neu kompiliert, mit dem gleichen Problem. CONFIG_LIRC=m und CONFIG_IR_LIRC_CODEC=m sind gesetzt, und auch sonst alle CONFIG_IR_* ausgewählt.

Beim lirc-Programm habe ich das Problem, dass nur ein Treiber geladen werden kann, und ich habe keine Idee, welcher: Die Auswahl ist riesig: accent act200l act220l adaptec all alsa_usb animax asusdh atilibusb atiusb audio audio_alsa avermedia avermedia98 avermedia_vdomate awlibusb bestbuy bestbuy2 breakoutbox bte bw6130 caraca chronos commandir cph06x creative creative_infracd devinput digimatrix dsp dvico ea65 ene0100 exaudio flyvideo ftdi gvbctv5pci hauppauge hauppauge_dvb hercules_smarttv_stereo i2cuser igorplugusb iguanaIR imon imon_24g imon_knob imon_lcd imon_pad imon_rsc inputlirc irdeo irdeo_remote irlink irman irreal it87 ite8709 knc_one kworld leadtek_0007 leadtek_0010 leadtek_pvr2000 livedrive_midi livedrive_seq logitech macmini mediafocusI mouseremote mouseremote_ps2 mp3anywhere mplay nslu2 packard_bell parallel pcmak pcmak_usb pctv pixelview_bt878 pixelview_pak pixelview_pro provideo realmagic remote_wonder_plus remotemaster sa1100 samsung sasem sb0540 serial serial_igor_cesko silitek sir slinke streamzap tekram tekram_bt829 tira ttusbir tuxbox tvbox udp uirt2 uirt2_raw usb_uirt_raw usbirboy usbx userspace wpc8769l xboxusb zotac
("all" bedeutet, dass man trotzdem den richtigen Treiber manuell einstellen muss...)

Versucht habe ich bislang usbx, userspace, inputlirc. inputlirc benötigt einen separaten Daemon inputlircd, dem ein passendes /dev/input/event* übergeben werden muss, aber ohne irgendwelche Logmeldungen, weiss ich natürlich nicht, welches; Default scheint /dev/input/event2 zu sein, was bei mir das erste freie ist, aber damit scheint es nicht zu gehen.

Die Reaktionen auf "irw" waren immer entweder (meist) "connect: No such file or directory" oder einfach ein Hängen. Bei usbx kam eine Logmeldung, dass /dev/lirc0 nicht existiert und die Hardware nicht initialisiert werden könne.

7
Sundtek MediaTV Pro / Sundtek unter Gentoo und inoffizielle Erweiterungen
« am: Mai 11, 2014, 01:59:25 Nachmittag »
Benutzer von Gentoo-Linux haben es wahrscheinlich schon gefunden. Dennoch will ich hier ankündigen, dass der mv overlay (der einfach mit layman installiert werden kann) ein inoffizielles(!) Ebuild für die Treiber enthält.

Für Benutzer anderer Linux-Distributionen ist vielleicht das _mediaclient zsh-completion file interessant, das für zsh-Nutzer Vervollständigung der Optionen des mediaclient-Kommandos erlaubt: einfach in den $fpath (i.d.R. /usr/share/zsh/site-functions) legen. Desweiteren gibt es ein mediaclient.{video,radio,dvb} script, das die Option -d von mediaclient automatisch passend ergänzt, wenn man nur ein Sundtek-Device hat. Beides kann man unmittelbar hier herunterladen:
http://git.overlays.gentoo.org/gitweb/?p=user/mv.git;a=tree;f=media-tv/sundtek-tv/files
(für mediaclient.{radio,dvb} tun es Symlinks auf mediaclient.video).

Wohlgemerkt, das Ebuild und beide Skripte sind inoffiziell, und es wird natürlich keine Haftung übernommen.

Die Vorteile, wenn man über ein Ebuild installiert, sind klar: Der Paketmanager kennt die installierten Files, passt auf Kollisionen auf, kann selbst deinstallieren, usw. Für hardened-Nutzer (mit PAX-Kernel) von Gentoo werden bei der Installation die notwendigen Rechte vergeben, wenn das entsprechende USE-Flag gesetzt ist.

Edit: Eine Bemerkung zur Handhabung des Ebuilds wurde aus diesem Posting gelöscht, da nach der Diskussion in diesem Thread ein "reguläres" Ebuild möglich ist.

Edit 2: Problembeschreibungen entfernt, da diese in getrennte Threads gehören.

Seiten: [1]