Ich würde hier dann immer noch eher auf einen Hardware-Schaden (Box, USB-Port/-Kabel oder Stick) tippen als auf ein "vergeßliches" SMB-Protokoll, das einfach irgendwelche Daten ausläßt - auch das beschriebene Verhalten beim Indizieren des Sticks deutet für mich eher auf Lesefehler und jede Menge Wiederholungen (oder zumindest Versuche einer solchen) hin ... vielleicht stört hier aber auch mal wieder das WLAN den USB-Transfer, denn irgendeine kalte Lötstelle an einem Schirm kann auch alle Vorkehrungen gegen solche Interferenzen unterlaufen.
Wobei man auch das "wear leveling" bei einem USB-Stick nicht unterschätzen darf ... die Schreibraten auf einen solchen Stick sind (wenn es nicht gerade wirklich "hochpreisige Hardware" ist, deren Controller mit allen möglichen Kniffen solche Einbrüche zu vermeiden versucht) nicht zwingend linear und wenn es da über größere Zeiträume einen Einbruch gibt, werden die Buffer im OS eben auch nicht schnell genug geleert.
Gerade beim Schreiben größerer Dateien bzw. Datenmengen dürfte man früher oder später mit dem "wear leveling" Bekanntschaft schließen ... daher teste ich irgendwelche Durchsatzraten dann auch lieber mit einer "echten" HDD ("seek times" kann man bei leerer HDD auch weitgehend ignorieren und deren Controller müssen zwar auch eine Leseprüfung ausführen, aber zumindest die Daten nicht noch intern umsortieren oder gar komprimieren, denn dann kommt es auch wieder auf den Inhalt der Daten an und wie gut sie sich komprimieren lassen), bei der zwar auch Verzögerungen einzupreisen sind, aber diese sind einigermaßen konstant und lange nicht so erratisch, wie bei einem flash-basierten Speicher, dessen Controller noch eine weitere Verwaltungsschicht zwischen Flash-Chip und USB-Interface einzieht.
Wenn auch bei der Wiedergabe WLAN involviert ist, interessieren
durchschnittliche Übertragungsraten ja nicht wirklich, auch nicht bei MPEG-Daten (und ja, ich kenne mich auch mit MPEG ein wenig aus ... ich hoste auf meiner Domain "winnt.de" noch heute eine Kopie des Programms "
Mpeg2Schnitt" für den Autoren und habe früher selbst mit Leidenschaft TS-Streams repariert, zerlegt, geschnitten und wieder gemixt), solange da nicht so viel gepuffert wird, daß wirklich jede Schwankung in der Übertragung ausgeglichen werden kann.
Was mich vor allem interessiert ... wie genau soll denn AVM (bzw. AVM-Software) daran Schuld sein, wenn/daß eine Datei bei der Speicherung auf dem USB-Stick verfälscht wird? Das sind ja (beim SMB-Zugriff) alles keine Protokolle, wo man mal eben irgendein Paket droppen kann ... fehlt da eines, wird es halt noch einmal angefordert und übertragen. Damit hat die von AVM selbst erdachte Software aber nun wirklich nur noch sehr am Rande zu tun und warum und vor allem was sollte man da an der SMB-Komponente der Firmware ändern?
Oder ist das (die 7590 beobachte ich mehr aus dem Augenwinkel und nicht sehr intensiv) jetzt bei diesem Modell tatsächlich neuer Samba-Code? Das wäre sehr überraschend ... aber auch das Thema hatten wir jüngst irgendwo, daß SMB1 ja eigentlich nicht mehr genutzt werden sollte und die bisher von AVM eingesetzte Samba-Version noch kein SMB2 beherrscht.
Ansonsten ist vermutlich der USB-Code für den GRX5 noch recht "jung" (die USB3-Ports der 7490 wurden über einen gesonderten Chip angebunden, der
GRX350 hat den USB3-Controller integriert) und das beobachtete Verhalten mit dem kompletten Schreiben aller Buffer, bevor weitere Daten entgegengenommen werden, könnte auch daher kommen ... ich würde zumindest mal probehalber auch mal zwischen USB2 und USB3 umschalten und prüfen, ob das einen Unterschied macht. Das eigentliche Kunststück ist es in meinen Augen nämlich eher, die FRITZ!Box mit GRX5-Chipset davon zu überzeugen, daß die Hardware auch den USB3-Modus beherrscht ... allzu oft wird die nur als USB2-Gerät eingebunden, obwohl sie USB3 beherrscht (das konnte ich zumindest auch auf 7590-Boxen bei anderen beobachten).
Bei mir werden jedenfalls übertragene Dateien beim Speichern auf einen USB-Stick (mit stark schwankenden Übertragungsraten, da spielen eben sehr viele Faktoren hinein) tatsächlich auch 1:1 auf dem Speicher abgelegt ... das wäre ja auch noch schöner, wenn dabei Verfälschungen auftreten würden, denn nicht alles kommt mit fehlenden Daten so gut klar, wie das MPEG kann bei fehlenden Frames.
Die Übertragung von 4,5 GB (ich habe mal eine ältere ISO-Datei mit Leap 42.3 genommen) dauert zwar ihre Zeit (auf einen SanDisk Ultra Fit mit 32 GB im USB2-Modus 12 Minuten und im USB3-Modus 9,5 Minuten - alles auf eine "ext3"-formatierte Partition), erzeugt aber (auch in mehreren Kopien) immer wieder dieselbe Datei auf dem Speicher-Stick. Der dabei durchschnittlich erzielte Durchsatz von 8,5 MByte/s (beim USB3-Mode) ist zwar nicht wirklich gut, aber mit einer HDD auch höher als mit dem SanDisk-Stick.
Mir fehlt aber eben auch die Phantasie, wo AVM da für Defekte in gespeicherten Dateien auf einem USB-Stick direkt verantwortlich sein sollte bzw. welche "AVM-Komponente" da die Schuld tragen sollte. Auch kann ich mich nicht so richtig erinnern, daß jemand (mit funktionierender Hardware) schon einmal ähnliche Beobachtungen gemacht hätte - bei NTFS-formatierten Volumes würde ich es ggf. noch verstehen, weil dieser Code eben auch "neu" ist (zumindest in der dargebotenen Form eines Kernel-Drivers).
