NFS vs SMB

    Hi,

    ich hab in letzter Zeit des Öfteren mit 4K Inhalten (MKV) und dementsprechend großen Dateien zu tun, die über mein "NAS" (TV Box mit Armbian und einer angeschlossenen 2 TB SSD) gestreamt werden. NFS und SMB sind aktiviert. Beide liefern beim Datentransfer ähnliche Transferraten (ca. 80 MB/s stabil beim Kopieren eben jener Dateien im Filemanager in Kodi). Die CPU Auslastung auf der Box ist auch ähnlich groß (20 - 30%).

    1080p Inhalte haben sich über SMB problemlos auf meinem Fire TV Max mit Kodi Omega Maven Build (per LAN angeschlossen) abspielen lassen. 4K Inhalte (> 10 GB) buffern immer wieder und zwar ewig.

    Das Log liefert nichts spannendes. Über NFS läuft alles problemlos. Ist SMB nicht für größere Dateimengen gedacht oder ist NFS für das Abspielen von Inhalten einfach besser geeignet?

    Ich hab mit NFS im Grunde keine Probleme allerdings sind Apps (Fire TV, SmartTV usw.) oft nicht in der Lage sich per NFS zu verbinden. Aktuell läuft beides parallel und ist noch kein Problem, ich denke allerdings dass es das in Zukunft werden könnte wenn lokale Inhalte immer größer werden sollten.

    Kommt drauf an...

    Ich dachte frueher auch immer, das NFS weniger overhead had und besser sein muesste, aber am Ende sind da zwischen der Platte wo der Film drauf liegt und dem Bildschirm wo er angezeigt wird unendlich viele Komponenten am Werkeln, die sich alle gegenseitig die Arbeit leichter oder schwerer machen koennen.

    Festplatten am Server legen sich gerne auch mal schlafen. Wenn da der Rest der Software sich mal schnell soviele Daten saugt, das die Platte mit dem Film z.b. 30 sekunden nix mehr lesen muss, dann schlaeft die vielleicht mal schon. Unwahrscheinlicher natuerlich bei Filmen mit hoehen Uebertragungsraten, aber bei niedrigen Raten ein beliebtes und nerviges Problem. Und sehr davon abhaengig wieviel da auch beim Filesystem gebuffert wird, was z.b. davon abhaengt, wieviel Hauptspeicher NAS und client haben.

    SMB auf Linux server ist gerne im Userland (Samba). Was es langsamer machen kann. gerade wenn die CPU langsam ist. In neueren Linux Kernels aber auch als VFS im Kernel. Was es schneller machen sollte. Aber auch einen Unterschied beim Bufferung macht.

    NFS kann TCP, was es ueber Links mit Paketverlusten wie WiFi anders verhalten laesst als SMB. Eigentlich sollte das besser sein beim NFS. Kann aber auch zu anderen Problemen fuehren. Aber ob man wirklich TCP verwendet haengt auch vom Client, Server und config ab.

    Auf der Client seite gibt es zudem noch den Unterschied, ob das Filesystem im OS oder in Kodi implementiert ist. Nachdem ja auf Windows oder Android NFS nicht vom OS unterstuetzt wird ist NFS dort immer im Kodi. Aber bei SMB habe ich den Eindruck, das Kodi da 'nur' das SMB vom unterliegenden OS nimmt. Was Kodi AFAIK frueher nicht gemacht hat. Das hat dann auch einen Einfluss auf die Performance. VLC z.b. nimmt immer seine eigene Implementierung von NFS und SMD AFAIK. Ist also immer ein guter Vergleichspunkt: Wenns mit VLC streamt, aber mit Kodi nicht - dann ist Kodi schuld. Ansonsten der Rest von der ganzen Kette.

    Habe sicherlich noch 99 andere Faktoren vergessen.

    Zusammenfassung: Das ist ein faszinierendes Thema wann man zufaellig arbeitslos geworden ist oder in den Ruhestand gegangen ist, und ein Hobby sucht um die Zeit todzuschlagen. Der Rest von uns versucht immer krampfhaft Tricks um es irgendwie mal zum laufen zu bringen, moeglichst ohne zu verstehen, warum. Weils einfach zuviele Faktoren gibt.

    Und dann muss man noch dazu sagen, dass etwas immer hilft. Nämlich halbwegs ordentliche Hardware mit einer Gigabit LAN-Schnittstelle.

    Dann ist es quasi egal, welches Protokoll man nimmt.

    Es macht halt einen Unterschied, ob ich einen FireTV 4K MAX per USB2LAN-Adapter nutze, oder eine Shield mit LAN-Anschluß.

    Ich nutze seit einiger Zeit bei mit unter Kodi das Embycon Addon und ich meine, dass der Stream da sogar via html aufgebaut wird und das läuft problemlos am Gigabit LAN der Shield Pro. ;)

    95% aller Computerfehler sitzen vor dem Bildschirm!

    Für mich war mal ein Grund von NFS auf SMB zu wechseln die Vergabe von Berechtigungen. Bei NFS konnte ich nur auf IP-Range-Ebene einschränken und man musste immer wieder mal den NFS-Export anstoßen, damit alle Clients das sauber hingekriegt haben. Mit SMB ware es einfacher über User/Passwort einzuschränken und feiner zu granulieren mit Lese-/Schreibberechtigungen.

    Bin aber kein Netzwerk-Experte und die Umstellung war vor Jahren. Bin aber gerade dabei, auf Linux bei den Clients zu wechseln (mit UnRaid als Server) und bleibe trotzdem bei smb.

    Zitat von talentfrei

    ich hab in letzter Zeit des Öfteren mit 4K Inhalten (MKV) und dementsprechend großen Dateien zu tun, die über mein "NAS" (TV Box mit Armbian und einer angeschlossenen 2 TB SSD)

    Schon mal einen Gedanken daran verschwendet, dass eine TV Box mit Armbian vielleicht nicht das gleiche ist, wie ein NAS? ;)

    Zitat von talentfrei

    4K Inhalte (> 10 GB) buffern immer wieder und zwar ewig

    :D :D Sorry, wenn ich da mal etwas schmunzeln muss ;) (und ja...ich schmunzel nur...ich lache dich nicht aus!!!!)

    Ich habe BRs (1080p) die sind 25GB groß und ich habe weder mit SMB noch mit NFS Probleme. Jetzt sagst du, dass du 4k Filme hast, also 2160p und die sind größer als 10GB ;) Das ist halt irgendein runtergeladener Kram. Das an sich ist erstmal kein Problem. Die Dateigröße hat aber erstmal nur bedingt was mit dem Puffern zu tun.

    Kleine Faustregel:

    Du hast Datei "1" mit Größe "X". Diese Datei ist ein Film mit einer Laufzeit von 2 Stunden. Wenn du diese Datei von "Gerät A" nach "Gerät B" über das Netzwerk mit einem der beiden Protkolle kopiererst und das Kopieren keine 2 Stunden dauert, dann sollte es beim Abspielen auch keine Probleme geben.

    Etwas Detaillierter:

    Auf dem obigen aufbauend...ich sage, dass die Dateigröße nur bedingt eine Rolle spielt weil es da noch einen ganz wichtigen Faktor gibt. Nämlich die "Laufzeit" des Films. Ein Beispiel....

    Du hast eine Datei, die ist 10GB groß und der Film hat eine Laufzeit von 2 Stunden (also 120 Minuten). Hier läuft das Abspielen des Films absolut problemfrei

    Dann hast du eine andere Datei, die ist ebenfalls 10B groß, hat aber nur eine Laufzeit von 10 Minuten. Hier wird es ganz fürchterlich puffern.

    Der Grund dafür ist die sogenannte Bitrate. Diese errechnet sich durch die Faktoren "Dateigröße" und "Laufzeit des Films". Ist diese Bitrate größer als die Rate des Transfers über eines der beiden Protokolle, dann ist es klar, dass es puffert.

    Jetzt sagst du, dass es über NFS geht, über SMB aber nicht. Grundlegend würde ich deinen Gedankengang unterstützen und sagen, dass wenn es über eines der beiden geht, dass es auch über das andere gehen sollte. Wie oben schon erwähnt wurde, gibt es da etliche Faktoren, die da mit rein spielen können. Ich habe die Erfahrung gemacht, dass SMB (CIFS) unter Linux mehr Probleme macht als NFS. Ich sage "Linux" weil sowohl dein "Server" als auch dein "Client" unixoide Betriebssysteme aufweisen.

    Weiter sind echte NAS Systeme im Auslieferngszustand auch besser ausgestattet und besser konfiguriert als irgendeine auf ARM-Technologie basierende TV-Box. Ich könnte dich jetzt noch fragen, was du auf der Serverseite noch alles an SMB-Server Konfigurationen vorgenommen hast. Kannst du das beantworten? Wenn ja, weißt du genau, was diese Server-Konfigurationen bewirken? Hast du versucht deinen SMB-Server besser zu konfigurieren?

    Zitat von talentfrei

    Das Log liefert nichts spannendes

    Liefert es nichts oder siehst du es nur nicht? Ich würde vermuten, dass das [definition='1','4']Debuglog[/definition] uns auf jeden Fall einige Informationen liefern könnte, die wir hier erfragen müssten. Zum Beispiel die entsprechende Bitrate des Films ;)

    Jetzt kommt es aber auch auf dich an. Möchtest du es analysieren und deine TV-Box anders konfigurieren oder möchtest du, dass es läuft? Wenn du letzteres möchtest, dann nimm das, was geht und schließ das Thema ab (also NFS). Wenn du es analysieren möchtest, dann werden wir mehr Logs brauchen ;)

    Danke schon mal für die Antworten. Hab mir schon gedacht dass es wohl nicht so einfach sein wird da den "Schuldigen" zu finden.

    b0mb

    Ich hatte lange eine Shields (2015, 2017 Modelle) aber die hatten immer wieder merkwürdige Probleme: Fernbedienung ist wie tot und lässt sich nicht mehr pairen, nach einigen Tagen Nutzung der TV Fernbedienung gehts sie plötzlich wieder. Flash Speicher läuft einfach immer wieder voll obwohl es keine großen Dateien gibt, geht nicht in den Standby bzw wacht davon nicht mehr auf oder wacht irgendwann Nachts auf und läuft dann durch. Da bin ich mit dem Cube 2 und dem 4k Max Stick eigentlich ganz gut gefahren.

    no.spam

    So ein ähnliches Problem hatte ich schon mal, das lag aber dann eher an der Kombination aus SMB und NFS. Alle Dateien und Ordner die vom SMB User angelegt wurden konnten über NFS nicht verändert werden. Dann mussten in OMV die Berechtigungen wieder rekursiv vergeben werden und dann ging das wieder.

    Zitat von DaVu

    Ich habe BRs (1080p) die sind 25GB groß und ich habe weder mit SMB noch mit NFS Probleme. Jetzt sagst du, dass du 4k Filme hast, also 2160p und die sind größer als 10GB ;) Das ist halt irgendein runtergeladener Kram. Das an sich ist erstmal kein Problem. Die Dateigröße hat aber erstmal nur bedingt was mit dem Puffern zu tun.

    Es ist kein "runtergeladener Kram" und auch keine 2h Filme sondern Episoden von Serien die so ca. 30 min lang sind, bei denen die zusätzlichen Sprachen und Audiofeatures die ich nicht nutzen kann entfernt wurden. Was die Konfiguration angeht hab ich nur die Optionen über OMV aktiviert und sonst nichts konfiguriert.

    Der einzige Unterschied zwischen NFS und SMB im Log sind eben folgende Einträge:

    Code
    2023-05-20 10:47:07.873 T:13254 warning <general>: OutputPicture - timeout waiting for buffer
2023-05-20 10:47:07.907 T:13254 error <general>: CMediaCodecVideoBuffer::ReleaseOutputBuffer error in render(false)
2023-05-20 10:47:15.054 T:13018 info <general>: Skipped 9 duplicate messages..

    Beim Abspielen über NFS tauchen diese nicht auf. Ich belasse es mal dabei und werde wohl erst mal NFS nutzen. Ich bin ja eigentlich eher jemand der Inhalte streamt, mal sehen ob ich mir nicht doch mal ein "echtes" NAS zulegen muss, wobei ich mit meiner Lösung bisher auch immer zufrieden war und sie vollkommen ausgereicht hat.

    Code
    2023-05-20 10:46:28.550 T:13239 info <general>: ffmpeg[0x85a3f430]: Duration: 00:34:40.61, start: 0.000000, bitrate: 19714 kb/s
2023-05-20 10:46:28.550 T:13239 info <general>: ffmpeg[0x85a3f430]: Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn (default)
    Zitat von talentfrei

    Der einzige Unterschied zwischen NFS und SMB im Log sind eben folgende Einträge

    Bitte keine Schnipsel. Immer nur vollständige Logs. Danke.

    Und ja...natürlich ist es klar, dass du keine Logeinträge für das Puffern hast, wenn es kein Puffern gibt ;) . Mich interessieren potentiell noch ganz andere Dinge im Log. Wenn du möchtest, dass wir dir helfen, dann musst du uns auch die Infos geben, die wir anfragen.

    Wenn du das nicht möchtest, dann viel Spaß bei der Fehlersuche ;) [dn]

    Wollte vorhin die Logs besorgen und dann gehts plötzlich. Hab dann festgestellt dass aus irgendeinem Grund die WLAN Verbindung aktiviert wurde. Nochmal ausgemacht - hängt wieder, wieder aktiviert - läuft einwandfrei. WiFi6 WLAN ist wohl besser für die Übertragung als 100 MBit LAN, ich dachte dass Stabilität mehr bringt als Durchsatz - naja wieder was gelernt. Die NFS/SMB Thematik war wohl nur das Zünglein an der Waage.

    Zitat von talentfrei

    Beide liefern beim Datentransfer ähnliche Transferraten (ca. 80 MB/s stabil beim Kopieren eben jener Dateien im Filemanager in Kodi).

    Meinst du Megabyte/s (da ist die korrekte Abkürzung MB/s) oder Megabit/s (Abkürzung Mb/s). Im Zweifel empfehle ich immer byte und bit auszuschreiben, grade bei Transferraten ist beides üblich - Filemanager zeigen oft Byte, Netzwerk-Monitore oft Bit.

    Frage insbesondere, weil ich halt zuerst Byte verstanden habe, du später aber schreibst:

    Zitat von talentfrei

    WiFi6 WLAN ist wohl besser für die Übertragung als 100 MBit LAN

    Damit sind natürlich die oben genannten 80 MByte/s nicht möglich.

    War ansonsten auch meine Erfahrung, dass modernes WiFi verlässlich bessere Übertragungsgeschwindigkeiten bringt, als 100 Mbit/s LAN. Auf meinen FireTV brachte ein GBit/s USB<->Ethernetadapter auch Geschwindigkeits-Steigerung ggü 100 Mbit LAN, allerdings an USB2 selbstverständlich bei weitem nicht die Gbit/s Geschwindigkeit. Im Endeffekt stellte sich heraus, dass ich auf den Adapter verzichten kann und WiFi (zumindest für meine Medien und meine örtliche Verhältnisse) mehr als genug und vollständig zuverlässig ist. Gab hier auch schon andere Threads, die ähnliche Ergebnisse bei FireTV hatten: besondere Testdateien, die sehr hohe Bandbreite benötigen liefen unter WiFi gut, bei 100 Mbit/s gab es Nachpuffern.

    Hat aber wenig mit SMB vs. NFS zu tun. Ich selbst (durchaus bewandert in Netzwerk-Tests und Netzwerk-Lasttests auch mit selbstgeschriebenen Tools) erkannte normalerweise keine großen Unterschiede zwischen NFS und SMB (bei sonst vergleichbaren Bedingungen). Oft genannte große Vorteile von NFS, insbesondere beim Übertragen/Bearbeiten vieler kleiner Dateien oder Auflisten großer Directories, konnte ich nicht wirklich nachvollziehen. Klar, "früher" konnte man schon einen etwas größeren CPU-Footprint von Samba vs. NFS feststellen. Spielt heute auf typischen (auch kleinen schwachbrüstigen) Servern meines Erachtens keine Rolle mehr.

    Würde da eher den in Kodi eingebauten Client-Code als Ursache vermuten.

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

    Zitat von DaVu

    Warum ist denn da eigentlich kein Gigabit? 100MBit ist ja eher so vor der Jahrtausendwende ;)

    Kein dein Router nicht mehr?

    Der Router kann schon mehr aber der Fire TV kann nicht mehr. Die Fritzbox zeigt sogar GBit LAN an (es ist ein Gigabit Adapter) aber bringt halt über USB 2.0 nicht viel. Es kann natürlich sein dass es als Gigabit LAN läuft und dann nur max 480 MBit/s erreichen kann ich glaube aber eher dass es 100 oder 1000 MBit/s sind alles dazwischen fällt auf 100 MBit/s runter

    Zitat von buers

    Meinst du Megabyte/s (da ist die korrekte Abkürzung MB/s) oder Megabit/s (Abkürzung Mb/s). Im Zweifel empfehle ich immer byte und bit auszuschreiben, grade bei Transferraten ist beides üblich - Filemanager zeigen oft Byte, Netzwerk-Monitore oft Bit.

    Frage insbesondere, weil ich halt zuerst Byte verstanden habe, du später aber schreibst:

    Damit sind natürlich die oben genannten 80 MByte/s nicht möglich.

    Es sind tatsächlich Megabyte/s. Allerdings muss da das WLAN aktiviert gewesen sein. Es aktiviert sich aus irgendeinem Grund immer wieder von selbst. Habe vorhin nochmal das WLAN explizit deaktiviert dann etwas kopiert und bin da nur auf knapp 20 Megabyte/s gekommen. Der Router ist tatsächlich ca 4m vom Router entfernt, ohne irgendwelche Geräte die aktiviertes WLAN haben oder Wände im Weg. Ich glaube auch dass du Recht hast, es hat wohl nicht viel mit SMB oder NFS zu tun.

    talentfrei, sicher, dass du da nicht irgendwo durcheinander gekommen bist, bei deinen genannten Übertragungsgeschwindigkeiten? Welches FireTV-Gerät genau hast du? (Sorry, wenn ich das überlesen habe). Mir ist kein FireTV Gerät mit USB3 oder mit Gbit/s LAN bekannt. (USB2 reicht bei weitem nicht für die genannte Übertragungsgeschwindigkeit). 80 MByte/s (die du in #1 nanntest) über Wifi hätte ich praktisch für ein Gerät wie FireTV für ausgeschlossen gehalten (allerdings habe ich keine Erfahrung mit dem Cube, aber mit vielen anderen FireTV-Geräten).

    Amazon Fire TV - Wikipedia

    Wenn du wirklich an die 80 MByte/s schaffst - ich kann mir nicht vorstellen, dass es Medien gibt, die das benötigen - auch nicht kurzzeitig. Jedenfalls aktuell nicht im Hobby-Kino-Bereich.

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

    Und genau deswegen hätte ich halt gern mal ein Log gesehen. Also ein vollständiges. Dann wüssten wir auch mehr über die Bitrate. Die ist ja nun auch nicht so ganz unwichtig.

    Zitat von buers

    talentfrei, sicher, dass du da nicht irgendwo durcheinander gekommen bist, bei deinen genannten Übertragungsgeschwindigkeiten? Welches FireTV-Gerät genau hast du? (Sorry, wenn ich das überlesen habe). Mir ist kein FireTV Gerät mit USB3 oder mit Gbit/s LAN bekannt. (USB2 reicht bei weitem nicht für die genannte Übertragungsgeschwindigkeit). 80 MByte/s (die du in #1 nanntest) über Wifi hätte ich praktisch für ein Gerät wie FireTV für ausgeschlossen gehalten (allerdings habe ich keine Erfahrung mit dem Cube, aber mit vielen anderen FireTV-Geräten).

    Amazon Fire TV - Wikipedia

    Wenn du wirklich an die 80 MByte/s schaffst - ich kann mir nicht vorstellen, dass es Medien gibt, die das benötigen - auch nicht kurzzeitig. Jedenfalls aktuell nicht im Hobby-Kino-Bereich.

    Wie bereits erwähnt es ist ein Fire TV 4k Max mit einer USB 2.0 Schnittstelle. Da hängt ein Gigabit USB LAN Adapter dran der von der Fritzbox auch als solcher erkannt wird. Kann aber natürlich nicht mit der vollen Geschwindigkeit laufen (geht ja physikalisch schon nicht). Aus irgendeinem Grund aktiviert sich das WLAN immer wieder von selbst und das ist wohl der Grund weshalb ich auf die 80 Megabyte/s komme. Wenn ich explizit vorher das WLAN deaktiviere und dann eine Datenübertragung in Kodi starte komme ich wie gesagt auf knapp 20 Megabyte/s. Außer Kodi lügt mich an oder das MB/s steht in Kodi Megabit was ich mir nicht vorstellen kann. Vielleicht werden auf LAN und WLAN kombiniert keine Ahnung.

    Ich schaue mal ob ich es heute schaffe die Logs nochmal abzuziehen.

    Thema

    Der Chromecast with Google TV Fred (GCCwGTV)

    Die Versionen und der Name

    Der offizielle Name ist anscheinend wirklich "Google Chromecast with Google TV 4K", oder abgekuerzt GCCwGTV4K. Ich nenne sie im folgenden nur "die Kiste". Es gibt auch eine HD Variante, die nur HD kann. die wurde ein wenig spaeter veröffentlicht und ist ca. 20 Euro billiger.

    (Offizielle) Spezifikationen

    https://store.google.com/product/chromecast_google_tv_specs

    Unterschiede zwischen HD und 4K Versionen

    GCCwGTV HDGCCwGTV 4K
    Erschienen20222020
    VideoHD mit 60 FPS HDR10 HLG4K
    …
    te36
    24. Mai 2023 um 03:22

    Aka: meine GCCwGTV schafft 200Mbps über WiFi, aber bloss 50Mbps über Ethernet. Allerdings noch nicht geschafft, das mit NFS oder SMB zu messen, sondern nur mit einer Speedtest App. Irgendwelche Vorschlaege, wie man am besten den Durchsatz auf der Kiste fuer SMB/NFS messen koennte ?

    Nachdem ich vor kurzem ein Ähnliches Problem hatte dachte ich geb mal meinen Senf dazu.

    Bisher hab ich ausschließlich SMB genutzt was bei meinen älteren Geräten wie Fire TV 4K Max und dem alten Fire TV 4K Stick einwandfrei funktioniert hat, auch bei 4K MKVs über 70 GB. Genutzt wurde WiFi 6e oder WiFi 5. Die Daten kommen von einer Festplatte die an meiner Fritzbox hängt.

    Seit kurzem hab ich einen Fire TV Cube 3rd Gen und hab laut Speedtest eine Bandbreite von über 640 MBits die am Cube ankommen über WiFi. (1 GBit gibt der Anschluss her). Also vollkommen in Ordnung und mehr als ausreichend.

    Trotzdem konnte ich fast keine Datei über 50 GB abspielen ohne alle 10-15 Sekunden aussetzer zu haben. Per LAN ging es etwas besser aber da war die Bandbreite einfach nicht ausreichend. Der Cube hat nur 100 MBit LAN.

    Hab ewig nach der Lösung gesucht, mit dem Cache gespielt usw. usf.

    Lösung war am Ende dann die Filme per FTP an den Cube weiterzugeben. Seitdem läuft alles einwandfrei. Was genau da falsch gelaufen ist weiß ich nicht. Fakt ist über SMB ging es nicht und über FTP einwandfrei. Betrifft auch nur meinen Fire TV Cube der sogar am nähesten am WiFi Router dran ist.

    Ich hab vorhin das hier erspäht:

    Das könnte in Kombination mit dem Protokoll Probleme bereiten, außerdem: Du startest eine Anwendung die das SMB oder NFS Protokoll eingebaut hat, je nachdem wie das in der Anwendung eingebaut ist, könnte da schon ein Problem liegen. Es könnte sein, dass es wenn es wie bei der Shield (bei SMB) ist und das Einbinden über das Betriebssystem erfolgt es weniger/keine Probleme gibt.

    Der FTP Hinweis ist auch nicht verkehrt für diejenigen die ihr Problem bisher nicht lösen konnten

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden