[solved] gmx-mediacenter via webdav (davfs) - Thunar friert ein

[ingo2]

Folgendes "unschöne" Verhalten zeigt Thunar, wenn ich ein 1,5GB großes Video (mpeg4 im mkv-Container) hochlade:

erstmal geht der Upload grottenlahm mit 170kB/s obwohl mein DSL-Anschluß 10Mbit/ (ca. 1,2M-Bytes/s) kann - da bremset wohl GMX den Upload.

Während des Uploads (kopieren in Thunar) ist Thunar eingefroren und reagiert nicht mehr.
Aber jetzt kommt das Schönste:
Am nächsten Tag habe ich wieder das Mediacenmter geöffnet und will mit Thunar den hochgeladenen Film in ein anderes Unterverzeichnis verschieben, da beginnt ein Download mit voller Speed von 7MB/s von - ich hab's mit der FritzBox gezählt - 4,2GB und Thunar ist wieder eingefroren. Kann diese Riesenmenge bei 1,5GB Nutzdaten dadurch entstehen, dass die Übertragung TLS-verschlüsselt und dann noch z.B. Base64 kodiert wird?

So, wie ich das bis jetzt verfolgen konnte, erfolgt dieser Download offenbar nur um einen 2 Zeilen Eintrag in ~/.local/share/gvfs-metadata/ zu machen (einen Hash der Video-Datei zu berechnen?).

Im Forum hier gab's den Tipp, in der Konfiguration

Code: Alles auswählen

/usr/share/dbus-1/services/org.gtk.vfs.Metadata.service

die Exec-Zeile zu kommentieren - das hat aber etlichen Komfortverlust, z.B. merkt sich Pluma nicht die letzte Kurserposition, und weitere bequeme Dinge.

Gibt's da eine andere Lösung, die Metadaten-Sammelei nur bei remote-Filesystemen abzuschalten?

Gruß, Ingo

[MSfree]

erstmal geht der Upload grottenlahm mit 170kB/s obwohl mein DSL-Anschluß 10Mbit/ (ca. 1,2M-Bytes/s) kann - da bremset wohl GMX den Upload.

DSL-Anschlüsse haben unterschiedliche Download- und Uploadgeschwindigkeiten. Typischerweise ist der Upload um den Faktor 10 langsamer als der Downlink. Folglich sind 170kB/s schon sehr gut für einen 10MBit/s DSL-Anschluß.

[ingo2]

Folglich sind 170kB/s schon sehr gut für einen 10MBit/s DSL-Anschluß.

Ich habe einen VDSL-Anschluß mit 10Mbit/s upstream und 50Mbit/s downstream.

[unitra]

Ich habe kurz recherchiert und gelesen, dass das beschrieben Problem nicht bei Thunar zu suchen ist sondern bei GVFS. Es gibt 2 möglichkeiten WebDAV zu benutzen einerseits mit GVFS oder dann mit davfs2.

https://manpages.debian.org/testing/dav ... .8.en.html

Veruschs mal mit davfs2 anstatt mit GVFS. Die Bugtracker sind voll mit der von Dir bezeichneten Fehlerbeschreibung. Leider nur immer nie gelöst bei den meisten Distros, weil Supportzeitraum zu Ende -> Bug zu. Wenn es mit Thunar nicht geht (ich habe kein debian hier) dann könnte man einen anderen Dateimanager installieren der davfs2 unterstützt.

[ingo2]

Veruschs mal mit davfs2 anstatt mit GVFS.

Das ist bisher schon so eingerichtet, habe in der fstab die Zeile

Code: Alles auswählen

https://mediacenter.gmx.net  /home/ingo/gmx.mc  davfs  noauto,user  0 0

und meine Login-Daten in der "~/.davfs/secrets".

Habe jetzt nochmals recherchiert und auch weit in die Vergangenheit zurück. Dabei habe ich dann u.a. diesen Link http://skripta.de/Davfs2.html gefunden. Betrifft zwar die Telekom, aber die gleiche Konfiguration wird auch für GMX empfohlen:

Code: Alles auswählen

     if_match_bug 1
     use_locks 0
     cache_size 1 
     table_size 4096
     delay_upload 1
     gui_optimize 1

mit dem Kommentar

Diese Einstellungen sind wichtig fuer das korrekte Funktionieren von Up- und Download

Das habe ich jetzt mal einfach so bei mir eingesetzt bis auf "table_size" die habe ich auf dem Defaultwert von 1024 belassen, da ich nur wenige Dateien dort ablege.

Dann habe ich noch was ganz aktuelles gefunden:
GMX hat sein Mediacenter jetzt in "GMX Cloud" umbenannt mit einer anderen URL:
https://webdav.mc.gmx.net - die wird auch zu einer anderen IP aufgelöst, also andere Hardware.
Die habe ich jetzt in der fstab eingesetzt statt der alten - und siehe da - der Upload ist jetzt fast 10x so schnell wie vorher und ist mit 1,4MiB/s das Limit meines DSL-Anschlusses.

Also zumindest schon mal ein großes PLUS!

Auch das Cache-Verhalten hat sich mit der neuen Konfiguration stark geändert, es scheint jetzt wirklich vernünftig und nach einer Weile warten ist der davfs-cache wieder leer (hatte da bei den alten Versuchen teils riesige Dateien mit entsprechenden Speicherverbrauch dauerhaft stehen.

Werde jetzt mal weiter beobachten und experimentieren - dann sollte es sauber gehen.

Ingo

EDIT 1:
Die einzige einigermaßen brauchbare Doku zu den davfs2-Parametern habe ich hier http://manpages.ubuntu.com/manpages/tru ... onf.5.html gefunden. Weiß da Jemand noch was zur Optimierung für Desktop-User?

[ingo2]

So, jetzt steht der Schuldige endgültig fest: Gnom's gvfs

Was ich jetzt alles getestet habe:

a) Mounten des mediacenters als webdav-share
- aber komplett ohne dass GVFS davon was mitbekommt. Dazu in der fstab den Parameter x-gvfs-hide angefügt. Das geht auch nicht so einfach wie bei normalen Dateisystemen, sonst meckert nämlich der mount Befehl und bricht ab. Muß in diesem Falle so angegeben werden:

Code: Alles auswählen

https://webdav.mc.gmx.net	/home/ingo/gmx.mc  davfs  noauto,rw,user,comment=x-gvfs-hide  0 0

Dann kann ich problemlos alle Aktionen (kopieren, löschen, verschieben) im Terminal machen ohne dass die graphische Oberfläche davon was mitkriegt und einfriert. Erst, sobald ich dann mit einem graphischen Tool (z.B. Thunar) mir den Inhalt des gemounteten Share anzeigen lasse, geht der Ärger los. Dann startet GVFS mit der Erzeugung von Metadaten und läd' dazu dann geänderte Dateien komplett runter und bläht den Cache auf (wohl um eine UUID davon per Hash zu generieren). Wartet man die ganze Aktion ab (kann dauern bei Videos) ist der sichtbare Erfolg davon ein "schönes" Icon

b) Bearbeiten des Webdav-Share komplett innerhalb Thunar:
Einfach in der Adresszeile die URI der GMX-Cloud in dieser Form eingeben

Code: Alles auswählen

davs://<username>@webdav.mc.gmx.net

Dann wird das Passwort abgefragt und alle Inhalte erscheinen recht flott im Thunar-Fenster. Von diesem Netzwerk-Share kann man jetzt einfach ein Lesezeichen setzen - fertig. Jetzt kann man problemlos alle Operationen in Thunar durchführen (upload, download, verschieben) ohne dass GVFS davon was mitbekommt und ohne das auch nur in der graphischen Darstellung irgendwas hakt oder ruckelt. Es wird alles innerhalb Thunar gehandelt. Der "schwere" Nachteil: die Dateien in der Cloud bekommen kein schönes buntes Icon

Leider zeigt die ganze Geschichte wieder Mal das agressive und rücksichtslose Verhalten von Gnome-Tools (hier Gnome-VFS), ohne dem User die Möglichkeit der detaillierten Konfiguration einzuräumen.
Eine ähnliche Odyssee war es, den Gnome-Keyring-Dämon zu zähmen, damit er mir nicht alle Anfragen zu Passwörtern meines GPG-Schlüssels vom Yubikey zur SSH-Authentifikaton wegschnappt - das macht nämlich der gnupg-agent sicherer und problemlos.

Ich setze das jetzt mal als gelöst.