"Quote"-Bug?
-
Wenn Filmtitel eben die “Anführungszeichen” enthalten, kommt beim Speichern ein “…ungültiges Argument”-fehlerfenster und Download bricht ab. Ist auch irgendwie logisch, wenn man überlegt, wie Dateinamen in Consolen & Co übergeben werden.
Abhilfe: Zeichen-Ersetzungtabelle: " durch ¨ (#168, diaeresis , double dot , umlaut ; sieht halbwegs ähnlich aus und bleibt im ASCII-Bereich) oder was anderes ersetzen lassen.
Erkenntnis: Ersetzungstabelle wirkt schon beim Anlegen des Downloads, wer zwischenzeitlich Ersetzungstabellen-Abhilfe schaffen will, muss trotzdem alle Downloads nochmal anschubsen.
Testumgebung: Java-Version: 14.0.2
OpenJDK 64-Bit Server VM Debian
MediethekView 13.6.039 Testobjekte: ARD: “Bon Courage”
evtl. relevant: Speichern erfolgt direkt auf einem FAT32-Laufwerk
Wieso ein Bug? : “Die Dateinamen werden für jedes Betriebssystem passend aufbereitet.”
Edit: Es scheint wirklich an dem FAT32 als Ziel zu liegen, das ist ja mal subtil. EXT4 beklagt sich nicht, aber NTFS vermutlich dann auch. Trotzdem, Quotes in Dateinamen sind immer leicht kritisch.
-
@ReneUX sagte: Es scheint wirklich an dem FAT32 als Ziel zu liegen
Hab das eben mit der Folge 20 von “Bon Courage” unter macOS getestet: Hier zumindest tritt das Problem bzw. die Fehlermeldung beim Speichern auf einen FAT32-formatierten USB-Stick nicht auf.
Das müsste also noch jemand unter Linux reproduzieren.
-
@styroll
Bei Linux bekomme ich auch die Fehlermeldung beim Speicherversuch auf FAT32. Auf EXT4 klappt’s.
-
Wenn du sicher bist, dass die Anführungszeichen schuld dran sind (ich konnte soeben problemlos einen Film vom Mac auf einen MS-DOS (FAT32) formatierten USB-Speicher kopieren), kannst du ja die Übersetzungstabelle entsprechend anpassen. Einstellungen -> Aufzeichnen und Abspielen -> Datei- und Pfadnamen.
Könnte aber auch an der Dateigrösse liegen, FAT32 kann, wimre, nur Dateien bis etwa 4 GB verwalten.
-
@mac-christian
Ich habe die kleinste Datei ausprobiert, an der Dateigröße liegt’s also nicht. Und ich habe schon seit Urzeiten die Quotes in der Ersetzungstabelle, das wurde auch im ersten Beitrag erwähnt. Für den Test habe ich sie kurz entfernt.
-
Im mediathekview.log taucht jeweils ein “File not Found” zusammen mit einer iO.Exception auf, wenn denn ""Quotes im Dateinamen auftauchen, vor denen die Ersetzungstabelle nicht im vorhinein beschützt. Könnte auch ein durchgereichter Fehler darunterliegender OS-Schichten sein? Unter Linux (EXT4) scheint " in Dateinamen erlaubte Praxis zu sein, während Windows (FAT32,NTFS) den Nutzer sehr-sehr gut davor beschützen wird, das “verbotene” Zeichen in Dateinamen zu tun. Würde sich jetzt Mediathekview per Default d’rum kümmern, währe auch ein fiktiver Linux-User denkbar, der den Bug meldet, dass “Quotes” nicht originalgetreu im Datenträger-Dateinamen auftauchen
Mac-Nutzer könnten noch testen, wenn denn sichergestellt ist, dass nicht die Ersetzungstabelle das " schon wegfiltert, welches Zeichen denn dann im Endergebnis an Stelle des " auf dem FAT32-Datenträger auftaucht, und evtl. auch mal vergleichen, welches, wenn so ein “unter Windows “böser”” Dateiname außerhalb von Mediathekview auf’s FAT32 geschubst wird.
Edit: ein “davor” eingefügt,
@MenchenSued
Unter Windows hatte ich glaub’ ich auch das " in der Tabelle, und wohl beim Linux-Umstieg gepennt, nur um dann eben früher oder später (jetzt) dieses unkritische Problemchen zu kriegen.
-
@ReneUX sagte in "Quote"-Bug?:
Würde sich jetzt Mediathekview per Default d’rum kümmern,
Ich würde ja eher dazu neigen, dass das Job des OS/des Filesystemtreibers wäre, sich darum zu kümmern, ob Filenamen zum verwendeten Filesystem passen.
Ich mein, von jedem Anwendungsprogramm zu verlangen, die Besonderheiten aller möglichen Filesysteme richtig zu handeln, die ein User einsetzen könnte, erscheint mir doch etwas Zuviel des Guten.
In diesem Sinne, hat MV m.E. eh dem User das richtige Werkzeug gegeben: Die Ersetzungstabelle.
-
@DaDirnbocher sagte in "Quote"-Bug?:
Ich würde ja eher dazu neigen, dass das Job des OS/des Filesystemtreibers wäre, sich darum zu kümmern, ob Filenamen zum verwendeten Filesystem passen.
Das tut es wohl und “findet” diesen “unerlaubte” Zeichen enthaltenden Dateinamen nicht und reicht den Fehler an MediathekView durch. Das Problem tritt (dann wohl korrekterweise) aber auch in anderen Anwendungen auf: Mittels Krusader (einem Dateimanager) “…”-kritische Datei vom EXT4 auf FAT32 kopieren → Krusader meldet dann « “…” konnte nicht geschrieben werden ».
Per Copy&Paste in PCManFM (anderer Dateimanager) EXT›FAT-kopieren bringt dann erst die korrekt-aussagekräftige Meldung « ungültiger Dateiname ».
-
@ReneUX Ja, aber wo ist jetzt ein Bug?
Wieso ein Bug? : “Die Dateinamen werden für jedes Betriebssystem passend aufbereitet.”
In Windows sind sie nicht erlaubt, da “filtert” sie MV ganz ohne Ersetzungstabelle.
In Linux sind sie nicht verboten (mit ext4 gehts ja), daher filtert sie MV dort nicht.
Beim macOS ähnlich.
Insofern passt die Aussage “jedes Betriebssystem passend” doch eh, oder?
Problematisch ist die Kombi Linux und FAT32, und letzteres ist wohl kein typisches Linuxfilesystem. Und selbst da stellt MV mit der Ersetzungstabelle ein passendes Werkzeug zur Verfügung.
-
@DaDirnbocher sagte in "Quote"-Bug?:
@ReneUX Ja, aber wo ist jetzt ein Bug?
→ Stimmt, ist eher kein Bug, nur ein Anwendungsfehler seitens des Anwenders
Sorry für alle unnötig gebundenen Kapazitäten.
