Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Denke nicht, glaube eher es hängt mit der Verarbeitung in MadVR zusammen. Bekommt man aber auch kaum raus wenn ich noch nicht mal ein Bild zu Gesicht bekomme.

Zumindest gehen 8Bit HEVC sachen aber nicht 10Bit, auch nicht Files.

Das dass Sys nicht überlastet ist sehe ich ja mit EVR/Custom EVR!

 

In leistungsschwächeren PCs sollte man madVR immer erst auf image up/down: DXVA2, Chroma up Bicubic stellen, enable windowed overlay hat bei mir auch geholfen wenn DVBV nicht fullscreen läuft.

 

Das Handling des DVBViewer ist mit madVR momentan sowieso erschwert, Drag'nDrop eines Files (dessen Auflösung egal) ins geöffnete Fenster führt oft zum Absturz, jedenfalls zu schwarzem Bild.

Auch ein Video pausieren führt zu schwarzem Bild.

Also sollte man DVBV jedesmal beenden bevor man ein neues Video auf sein Icon zieht, dann gehts.

 

Wenn man in den Favoriten den Astra UHD wählt bleibt es manchmal auch schwarz, dann gedulden, braucht manchmal bis 20sec bis ein Bild kommt, gelegentlich Absturz. Manchmal mußte ich 2x hin und her schalten, manchmal DVBV beenden und wieder starten und wieder gedulden. Wenn der Astra UHD einmal Bild hatte funktioniert das Umschalten etwas flüssiger.

 

Dann gibt es noch den Unterschied ob man 4K nun auch auf einem 4K-TV sieht oder nicht wegen scaling nein/ja. Das Downscaling auf 1080 hat bei meinen 4K Tests auf der schwächeren CPU mit madVR schon gereicht für Diashow trotz image down: DXVA2. Auf dem 4k TV dagegen liefen viele 4K videos (23-30Hz) auf dem starken i7-4790K auch mit madVR vollkommen ruckelfrei da unskaliert.

Auf dem schwächeren i5-3320M grad probiert läuft Astra UHD auch mit madVR mit obigen Einstellungen zwar als Diashow aber immehin hell.

 

EDIT:

>> Drag'nDrop eines Files (dessen Auflösung egal) ins geöffnete Fenster führt oft zum Absturz <<

funktioniert jetzt. Könnte am Lav Nightly liegen und/oder an image up/down: DXVA2 das war zu Anfang noch nicht eingestellt.

Beim Pausieren schwarzes Bild ist aber immernoch.

Edited by craig_s
Link to comment

 

Wenn aber der DVBViewer über den Source-Filter schon sehr früh das AR ändert, ist das etwas, das sich zwangsweise so auswirken wird, daß das geänderte AR zu früh kommt, und da sehe ich auch keine große Chance, das irgendwie zu fixen.

 

War auch nicht der Sinn meines Postings. Für mich ist das Verhalten so absolut in Ordnung. Hauptsache die 1080i > 720p Umschaltung funktioniert sauber. Wenn nun noch die Schwarzblenden beim Umschalten irgendwann weg kommen, sind die TV spezifischen Themen durch madVR aus meiner Sicht ganz gut abgedeckt.

 

Einziges offenes Problem ist dann für mich noch die Mauszeiger-Geschichte. Das muss ich mir noch im Detail anschauen.

 

 

Hab das bei manchen Splittern schon gesehen, daß dann halt die madVR-Queues nicht voll werden. Zumindest beim LAV Splitter ist das aber kein Problem.

 

Der DVBSource kann im Live-Fall natürlich nicht den Stream beschleunigen ;) . Da kann man mit dem Latenz-Parameter entgegen wirken, der die Timestamps um den definierten Wert in die Zukunft verschiebt, was die Puffer im Graph voller werden lässt. Mit 200ms und LAV Dekoder ist eine 32 tiefe Dekoder Queue im madVR aber stets gut gefüllt (Default ist ja 16).

Link to comment
Hattet ihr denn da Probleme mit Fremdkomponenten?

 

Reichlich in den vergangenen 12 Jahren. Abgesehen von Empfangs-Hardware wie DVB-Karten und Satelliten-Außenanlagen vor allem mit Decodern. Zur Zeit hauptsächlich mit MadVR :)

 

Vielleicht könnte man eine White-List von Fremdkomponenten machen, denen man vertrauen kann, und wo man darauf verzichen kann, schon im Source-Filter das Ausgabe-Rect umzustellen?

 

Pflegst du die Liste dann für uns? Und führst die dafür erforderlichen Tests regelmäßig durch? Mit sämtlichen in Frage kommenden Decodern und Renderern? :)

 

Scherz beiseite: So wie es ist, läuft es einigermaßen, und bevor wir das abändern und die damit verbundenen Risiken und den Zeitaufwand in Kauf nehmen, muss wirklich ein zwingender Grund vorliegen. Das Problem mit der MadVR Queue und der verfrüht stattfindenden AR-Behandlung im DVBViewer ist IMO keiner.

Link to comment

Ok ich hab dem MadVR unrecht getan, es geht auch in diesem nur darf der LAV nicht auf "DXVA2 (native)" stehen.

Im Übrigen verstehe ich jetzt auch warum der Cyberlink Generic bei HEVC flüssiger läuft, laut OSD von MadVR wird 10Bit UHD dann auf 8Bit gewandelt?!

Link to comment

 

Das Erste HD (mit eingeblendetem Mini-EPG OSD) > ProSieben HD

 

Das Mini-EPG-OSD von ProSieben HD wird ganz kurz eingeblendet und weicht dann wieder dem Mini-EPG-OSD von Das Erste HD, welches zuvor eingeblendet war. Das ProSieben HD Mini-EPG-OSD kehrt dann mit Erscheinen des Videos von ProSieben HD wieder zurück.

 

Übrigens kommt nicht nur das alte Mini-EPG-OSD nochmal zurück, sondern auch nochmal das letzte Video-Bild vom letzten Kanal. Da bleibt in der Present-Queue wohl noch ein Frame vom letzten Kanal hängen!?

Link to comment

Hmmmm... Manchmal kommt ein altes Frame, wenn man Direct3D zwischen Fullscreen- und Windowed-Mode hin und her schaltet. Das kommt dann von Direct3D und nicht von mir. Könnte es eventuell damit zusammen hängen? Tritt das Problem auch auf, wenn Du den FSE-Mode deaktivierst?

Link to comment

Ich verwende momentan kein FSE, ist also deaktiviert.

 

Wenn ich in den DVBViewer-Optionen "Fast channel switching" deaktiviere, kommt es nicht dazu. Da wird aber auch immer der Graph neu gebaut beim Umschalten...

Link to comment

Ok, passiert das auch mit deaktiviertem Deinterlacing? Ich vermute schon. Falls ja, kannst Du von einer vergleichbaren Situation wie dem Video mal ein Debug-Log machen? Vielleicht kann ich da was sehen...

Link to comment

 

Ok, passiert das auch mit deaktiviertem Deinterlacing? Ich vermute schon.

 

Richtig vermutet.

 

 

Falls ja, kannst Du von einer vergleichbaren Situation wie dem Video mal ein Debug-Log machen? Vielleicht kann ich da was sehen...

 

Siehe Anhang. Ich habe zweimal zwischen TNT Serie HD und TNT Glitz HD umgeschalten.

 

madVR - log.rar

Link to comment

Ok, das Log sagt:

 

1) 0 Sekunden: Wiedergabestart

2) 4,2 Sekunden: Graph wird gestoppt; der letzte präsentierte Frame ist ID 51 für VSync 210

3) 5,8 Sekunden: es kommen erstmals nach dem Stop neue Frames rein

4) 5,9 Sekunden: der erste Frame wird präsentiert; ID 73 für VSync 351; aktueller VSync ist erst 288

5) 6,7 Sekunden: Graph wird gestoppt; aktueller VSync ist erst 328, Playback hat also noch gar nicht richtig bekommen;

6) 8,5 Sekunden: es kommen erstmals nach dem Stop neue Frames rein

7) 8,6 Sekunden: der erste Frame wird präsentiert; ID 107 für VSync 480; aktueller VSync ist erst 422

8) 9,5 Sekunden: Graph wird gestoppt; aktueller VSync ist erst 466, Playback hat also noch gar nicht richtig bekommen;

9) 12,1 Sekunden: es kommen erstmals nach dem Stop neue Frames rein

10) 12,1 Sekunden: der erste Frame wird präsentiert; ID 141 für VSync 653; aktueller VSync ist erst 597

11) 13,1 Sekunden: endlich geht's los mit dem richtigen Playback; ID 142 wird präsentiert für VSync 654
12) 14,4 Sekunden: Ende.

 

Ich kann aus dem Log sehen, daß madVR beim Graph Stop alles Queues sauber leert. Und der Zeitabstand zum nächsten ankommenden Frame ist so riesig, daß auch alle schon an Direct3D geschickten Frames längst angezeigt sein müßten. Und nach dem Neustart des Graphs sieht auch alles sauber aus. Aus dem Log kann ich da nichts erkennen, das auf einen Bug in madVR hindeutet.

 

Hmmmm... Tritt das Problem nur auf, wenn das Umschalten so lange dauert, daß eine Schwarz-Blende kommt? Wenn ja, vermute ich, daß es vielleicht mit der Schwarz-Blende zusammen hängen könnte. Vielleicht bringt die irgendwas durcheinander, was aus dem Log nicht ersichtlich wird. Allerdings verstehe ich nicht so wirklich, warum das passieren sollte, denn das Malen der Schwarz-Blende ist ganz einfacher Direct3D-Code... :-(

Link to comment

Scheint tatsächlich damit zusammenzuhängen. Die Umschaltung zwischen Das Erste HD und arte HD ist sauber. Die sind unverschlüsselt und auf demselben Transponder. Da gibt es praktisch keine Verzögerung bei der Umschaltung.

Link to comment

Ich werd irgendwann demnächste (wenn ich etwas Zeit finde) mal eine Testbuild ohne Schwarzblende machen, und hier posten. Mal schauen, vielleicht verschwindet das Problem damit.

  • Like 1
Link to comment

Vielleicht interessant zur copyback Diskussion in madVR:

http://forum.doom9.org/showthread.php?t=171219&page=14

 

Im LAV Decoder wird es bald einen "direct mode" für DXVA copyback geben, der deutlich schneller sein und die Lücke zu DXVA native schließen soll.

Was mir dabei noch nicht klar ist: Für interlaced Quellen mit GPU-Deinterlacer wird dann trotzdem nochmal von madVR zurück kopiert?

Edited by nuts
Link to comment
  • 2 weeks later...
Im LAV Decoder wird es bald einen "direct mode" für DXVA copyback geben, der deutlich schneller sein und die Lücke zu DXVA native schließen soll.

 

Ist seit gerade eben raus.

http://forum.doom9.org/showthread.php?t=156191

 

Hab ich allerdings selbst noch nicht installiert/getestet.

 

- Faster: DXVA2 Copy-Back in direct output mode uses up to 50% less CPU and performance is improved accordingly

 

Edited by goldfield
Link to comment

Hier ist eine madVR-Testbuild (das madVR.ax einfach über die aktuelle offizielle Version drüber kopieren) mit zwei DVBViewer-spezifischen Änderungen:

 

http://madshi.net/madVRdvbViewerTest.zip

 

1) Die Schwarzblende nach einem Graph-Stop ist testweise deaktiviert. Ich hoffe, daß damit der Kanalwechsel besser funktioniert.

2) madVR setzt das Target-Rect jetzt nur noch nach einem Pin-Connect. Wenn sich z.B. die Videoauflösung ändert, ohne daß die Connection neu gemacht wird, sollte madVR jetzt das Target-Rect unverändert lassen. Ich hoffe, das behebt das Problem, daß manchmal das Target-Rect nicht stimmt, wenn der DVBViewer so eingestellt ist, daß er keine neue Connection macht, wenn sich die Auflösung ändert.

 

Wäre toll, wenn ich da Feedback bekommen könnte, ob die Änderungen funktionieren. Falls 1) wirklich hilft, ist die Testbuild noch keine endgültige Lösung, weil ich die Schwarzblende nicht komplett rausnehmen möchte. Aber zumindest wüßten wir dann, daß die Schwarzblende beim Kanalwechsel Probleme macht.

Link to comment

 

Wäre toll, wenn ich da Feedback bekommen könnte, ob die Änderungen funktionieren.

 

Da brauchst du dir keine Sorgen machen ;) .

 

 

 

2) madVR setzt das Target-Rect jetzt nur noch nach einem Pin-Connect. Wenn sich z.B. die Videoauflösung ändert, ohne daß die Connection neu gemacht wird, sollte madVR jetzt das Target-Rect unverändert lassen. Ich hoffe, das behebt das Problem, daß manchmal das Target-Rect nicht stimmt, wenn der DVBViewer so eingestellt ist, daß er keine neue Connection macht, wenn sich die Auflösung ändert.

 

Ich habe dafür die DVBViewer-Version installiert, die noch nicht auf EC_VIDEO_SIZE_CHANGED reagiert. Mit dem 0.87.14 Test-Build ist das Problem damit auch madVR seitig gefixt.

 

 

 

1) Die Schwarzblende nach einem Graph-Stop ist testweise deaktiviert. Ich hoffe, daß damit der Kanalwechsel besser funktioniert.

 

Dieses Problem ist leider nach wie vor vorhanden. Ich habe dafür nochmals Videos erstellt. Auch eine Gegenüberstellung zur Umschaltung zwischen Das Erste HD und ARTE HD, welche sauber ist. Ich habe ab und zu umgeschalten, während das Mini-EPG-OSD von der vorigen Umschaltung noch sichtbar war, und ab und zu gewartet, bis selbiges ausgeblendet wurde.

 

ProSieben HD / SAT.1 HD

Das Erste HD / arte HD

Link to comment

Übrigens... wenn man bei Datei-Wiedergabe auf Pause drückt, gibt es auch ein Rücksprungframe. Evtl. hängt das irgendwie zusammen!? Dafür braucht man aber ein aktuelles DVBViewer-Build...

Link to comment

Das heißt, es hat sich in dieser Hinsicht mit der Testbuild gar nichts verbessert, korrekt? Läßt sich das auch mit DVB-T irgendwie reproduzieren? Dann müßte ich mir da mal so'nen Stick oder so besorgen. An ein DVB-S-Kabel komm ich hier leider nicht ran.

Link to comment

 

Das heißt, es hat sich in dieser Hinsicht mit der Testbuild gar nichts verbessert, korrekt?

 

Korrekt.

 

 

Läßt sich das auch mit DVB-T irgendwie reproduzieren? Dann müßte ich mir da mal so'nen Stick oder so besorgen. An ein DVB-S-Kabel komm ich hier leider nicht ran.

 

Glaube ich nicht. Da erwarte ich mir eher das Verhalten vom Das Erste HD / arte HD Video. Bei den verschlüsselten Kanälen dürfte das Problem sein, dass sie einfach länger brauchen.

Link to comment

Hmm, ich habe jetzt mal beschissen und die Frames per DVBSource Latenz 2s weiter in die Zukunft geschedult und so die Wiedergabe nach dem Umschalten verzögert. Dennoch kein Problem bei der Umschaltung zwischen arte HD und Das Erste HD.

Link to comment

Das Erste HD und arte HD sind 720p und unverschlüsselt, während ProSieben HD und SAT.1 HD 1080i und verschlüsselt sind.

 

Ich habe jetzt noch zwischen 2 FTA 1080i Kanälen umgeschalten... Servus TV HD und Sky INFO. Auch hier ist die Umschaltung absolut sauber.

Link to comment

Ich habe die Umchaltung mit der 2s DVBSource Verzögerung jetzt mal genau unter die Lupe genommen:

 

arte HD / Das Erste HD:

Sofort nach der Umschaltung erscheint das OSD vom neuen Kanal sowieso ein Standbild vom neuen Kanal. Dann nach 2s laufen Video und Audio an.

 

ProSieben HD / SAT.1 HD:

Direkt nach dem Umschalten (ohne Verzögerung) erscheint ein schwarzes Bild sowie das OSD vom neuen Kanal. Nach gut einer Sekunde kommt dann der Rücksprung und gleich anschließend ein Frame vom neuen Kanal. Eine weitere Sekunde später laufen dann Audio und Video dann permanent an.

 

 

Das Problem dürfte sein, dass bei verschlüsselten Kanälen der Renderer einfach lange kein erstes Bild bekommt. Nur so am Rande... bei verschlüsselten Kanälen kann es locker 1-2s länger dauern, bis verwartbare Daten eintreffen. Beim Umschalten übergibt der DVBViewer erst die SID des zu entschlüsselnden Kanals an den Treiber. Der wartet dann auf die dazu passende PMT (PMTs haben in der Regel eine Zykluszeit von 300ms). Daraus generiert der Treiber nun die zum CAM passende CA_PMT. Das CAM setzt nun den Kanal im internen Descrambler/CSA auf und wartet anschließend auf ein ECM (typische Zykluszeit hier ist 200ms). Dieses muss dann an die SmartCard geschickt werden. Das CW kehrt dann ca. 200ms später zurück. Dieses wird nun in den CSA geschrieben und irgendwann spuckt selbiger dann entschlüsselte Pakete aus. Es dauert dann natürlich noch etwas bis die Daten vom CAM über das CI bzw. die Tunerkarte und den Treiber beim DVBViewer und schlussendlich im Dekoder bzw. Renderer landen...

Link to comment

Hmmmm... Das heißt, ich werd's hier mangels DVB-S-Kabel nicht reproduzieren können. Aber so ganz verstehe ich nicht, wieso das Problem nicht beim Wechsel von unverschlüsselt auf unverschlüsselt auftritt, selbst wenn Du künstlich eine Pause erzwingst? Wenn's nur an der Pause liegt, hätte Deine 2-Sekunden-Pause doch das gleiche Problem produzieren müssen? Kann es vielleicht an der CAM liegen, daß die vielleicht beim Umschalten noch alte Daten liefert? Aber warum das dann alte OSD, macht auch wieder keinen Sinn. Und das ganze tritt nur bei madVR auf, richtig? Auch wieder komisch. Wobei madVR allerdings auch anders funktioniert: madVR läßt den Splitter/Decoder schon laufen (solange bis die Queue voll ist), selbst wenn der Graph noch auf Pause steht. Dann machen andere Renderer meines Wissens nicht. Das könnte vielleicht auch ein anderes Verhalten im Splitter/Decoder provozieren...

 

Hmmm... Ich könnte vielleicht eine Test-Build machen, die die ersten 5 vom Decoder kommenden Frames nach einem Reconnect in BMP-Dateien auf den Desktop speichert. Meinst Du, das würde helfen, um dem Problem näher auf den Grund zu gehen?

Link to comment

 

Das heißt, ich werd's hier mangels DVB-S-Kabel nicht reproduzieren können.

 

Wahrscheinlich nicht mal mit unverschlüsseltem DVB-S. Evtl. mit einer langsamen DVB-Karte. Meine Digital Devices sind recht schnell...

 

 

Aber so ganz verstehe ich nicht, wieso das Problem nicht beim Wechsel von unverschlüsselt auf unverschlüsselt auftritt, selbst wenn Du künstlich eine Pause erzwingst? Wenn's nur an der Pause liegt, hätte Deine 2-Sekunden-Pause doch das gleiche Problem produzieren müssen?

 

Naja, die Frames kommen auch dann gleich schnell beim Renderer an, nur die Timestamps sind weiter in der Zukunft. Ich gehe davon aus, dass das Problem ist, dass bei verschlüsselt lange kein Frame kommt. Das ist unabhängig von der DVBSource Latenz gleich lange... Das erste Frame wird ja wie es scheint gleich gezeichnet...

 

 

Kann es vielleicht an der CAM liegen, daß die vielleicht beim Umschalten noch alte Daten liefert?

 

Das CAM selber puffert eher wenig. Es sind wenn dann die Treiber, die noch einiges entladen. Das war schon desöfteren ein Problem, wenn nach dem Umschalten noch PAT/PMT vom alten Transponder kamen. Ich sehe allerdings nicht, wie das hier dieses Phänomen provozieren sollte...

 

 

Und das ganze tritt nur bei madVR auf, richtig?

 

Richtig.

 

 

Hmmm... Ich könnte vielleicht eine Test-Build machen, die die ersten 5 vom Decoder kommenden Frames nach einem Reconnect in BMP-Dateien auf den Desktop speichert. Meinst Du, das würde helfen, um dem Problem näher auf den Grund zu gehen?

 

Du bist der Experte ;) .

Link to comment

Beim Tunen wird der Graph gestoppt und danach wieder gestartet. Vielleicht hängt es damit zusammen, wie lange sich der Graph im Stop-Zustand befindet?

Hmm, ich habe jetzt mal die Frames per DVBSource Latenz 2s weiter in die Zukunft geschedult und so die Wiedergabe nach dem Umschalten verzögert. Dennoch kein Problem bei der Umschaltung zwischen arte HD und Das Erste HD.


Das hat keinen Einfluss auf die Dauer des Stop-Zustandes und den Beginn der Datenlieferungen. Der Graph wird wie sonst auch sofort gestartet, die DirectShow-Streamtime beginnt zu laufen (ab 0), der Sourcefilter liefert sofort Daten, nur die DirectShow PTS verändern sich mit der Latency.

Link to comment

@Griga, kannst Du das von CiNcH berichtete Problem auch reproduzieren? Wäre es für einen von euch beiden ohne viel Aufwand möglich, eine Testbuild zu erzeugen, die die Situation mit dem langsamen Kanalwechsel simuliert, so daß ich das Problem hier reproduzieren kann (z.B. beim Abspielen von 2 Videos hintereinander, oder notfalls mit einem DVB-T-Stick oder so)? Ohne das reproduzieren zu können, wird das sehr schwer für mich zu fixen sein. Das von CiNcH produzierte Debug-Log sah für mich "sauber" aus. Von daher weiß ich gar nicht, wo ich ansetzen soll...

Link to comment

Hmmmm... Stimmt, zumindest sieht da irgendwas komisch aus: Wenn ich pausiere, kommt kurz ein altes Frame, dann erscheint direkt danach das aktuelle Frame mit nem Pause-Symbol drüber, allerdings auch nicht im korrekten AR! Wenn ich die Wiedergabe dann wieder starte, sieht aber alles ok aus. Ist das bei Dir genauso? Passiert bei mir so allerdings bei anderen Media-Players nicht! Naja, könnte aber mit dem OSD zusammen hängen, das machen andere Media-Player anders (nicht besser oder schlechter, sondern anders). Zumindest ist das etwas, das ich mir angucken kann. Mal schauen, ob es meine Schuld ist... :D

Link to comment
Wenn ich pausiere, kommt kurz ein altes Frame, dann erscheint direkt danach das aktuelle Frame mit nem Pause-Symbol drüber, allerdings auch nicht im korrekten AR!

 

Wenn ein Video Renderer kein OSD bei stehendem Bild ermöglicht (also bei allen außer dem Custom EVR), wird ein kurz vor der Ausführung von Pause angefertigter Screenshot als OSD-Hintergrund verwendet. Der Renderer ist damit bis zum nächsten Play aus dem Spiel.

 

@Griga, kannst Du das von CiNcH berichtete Problem auch reproduzieren?

 

Nein. Ich habe allerdings auch kein CI/CAM.

Link to comment

 

Wenn ein Video Renderer kein OSD bei stehendem Bild ermöglicht (also bei allen außer dem Custom EVR), wird ein kurz vor der Ausführung von Pause angefertigter Screenshot als OSD-Hintergrund verwendet. Der Renderer ist damit bis zum nächsten Play aus dem Spiel.

 

Ach sooo! Eigentlich sollte das madVR OSD bei *pausiertem* Playback aber noch funktionieren. Nur bei gestopptem Playback nicht. Aber nicht so wichtig, will es ja auch bei gestopptem Playback früher oder später lauffähig machen, da kann der DVBViewer vielleicht zu dem Zeitpunkt dann nochmal darauf abgestimmt werden...

Link to comment
  • 2 weeks later...

Klar, der Einfachheit halber erstelle ich ein Screenshot kurz bevor der Graph pausiert, oder gestoppt wird und arbeite mit dem Screenshot als Hintergrund. Das ist jetzt nicht wirklich schlimm.

Link to comment

Schön, das zu hören.

 

Bleibt nur zu hoffen, das die erste öffentliche Beta (ich gehe mal davon aus, das sowas geplant ist) nicht mehr lange auf sich warten lässt.

Die Kleinigkeiten "vernabbeln" sich dann im Einsatz mit der Zeit.

Edited by goldfield
Link to comment

Ich vermute es wird eine öffentliche Beta geben.

Im Moment werden auch cinchs Verbesserungen für den EVR Custom eingebaut und daher kann das noch etwas dauern.

 

Zu frühe öffentliche Beta Tests machen imho keinen Sinn. Lasst uns lieber in Ruhe die gröbsten Probleme aussortieren, wobei ich die Ungeduld natürlich verstehen kann. ;)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...