Plausibilitaetscheck fuer geaenderten Dateinamen
-
Ich benutze MV unter Ubuntu Linux. Dabei kann folgendes passieren:
Wenn man den Dateinamen vor dem Download aendert, kannt man nach der file extension (z.B. .mp4) versehentlich noch ein Leerzeichen eingeben. Das passiert sehr leicht beim copy & paste. Linux interessiert das ueberhaupt nicht - der spielt das file ohne zu murren, aber wenn man die Datei unter Windoof abspielen willst, weiss es damit nix anzufangen.
Und mit Windows-Bordmitteln kann man das Leerzeichen hinter der Dateierweiterung nicht loeschen.
Aehnliches gilt fuer Sonderzeichen, die unter Windows nicht erlaubt sind, z.B. Fragezeichen.
Solange man in der Linux-Welt bleibt, laeuft alles. Aber meistens will man die Filmchen ja auch woanders abspielen. -
@hein-bloed Dafür gibt’s die Ersetzungstabelle. Leerzeichen lasse ich grundsätzlich durch einen Underscore ersetzen, aber bei Sonderzeichen hilft nur das manuelle Nacharbeiten, denn irgendein Zeichen vergisst man bestimmt. In letzter Zeit kommen mir auch diverse Filme unter, bei denen Umlaute verstümmelt werden, ich habe aber noch nicht geschaut, ob es einen bestimmten Sender betrifft. Bei meiner geringen Anzahl von Downloads kann ich das aber einzeln checken
MediathekView 14.1.0, Linux Mint 21.3, VLC 3.0.16
-
@menchensued Ich habe den Dateinamen editiert im Fenster ‘download editieren’, also durch Doppelklick auf den Download-Pfeil. Und der Dateiname, der dort steht, ist ja schon von der Ersetzungstabelle bearbeitet worden. Wenn ich nun manuell - beabsichtigt oder versehntlich - irgendwelche nicht zulaessigen Zeichen hineinschreibe, wird der Dateiname ohne Plausibilitaetscheck uebernommen.
Soweit ich mich erinnere, geht das auch mit der Win-Version. -
@hein-bloed In der Hilfe zum Dateinamen steht
“Die Dateinamen werden für jedes Betriebssystem passend aufbereitet.”
Für Windows dürfte also kein “?” im Dateinamen auftauchen. Für den Austausch der Medien sollte vielleicht nicht unterschiedlich auf Betriebssysteme reagiert werden sondern die kleinste gemeinsame Menge verwendet werden - könnte man ja in der nächsten Version machen. Aber auch unter Linux gibt es manchmal Probleme mit Klammern, die ein Skript als Funktion interpretieren möchte oder Fragezeichen, die als Platzhalter dienen können.
Deine Frage, was mit manuell eingegebenen Namen passiert, beantwortet die Beschreibung nicht, das kann nur ein Entwickler klären.
MediathekView 14.1.0, Linux Mint 21.3, VLC 3.0.16
-
@menchensued OK, ist ja kein KO-Kriterium. Eher etwas, was in den seltensten Faellen auftaucht. Und die Leute, die dieses Problem haben, wissen vermutlich auch, wie sie es loesen koennen.
Gute Idee, diesen Hinweis zur Beruecksichtigung bei neuen Versionen an die Entwickler zu geben. Die Funktion “Die Dateinamen werden für jedes Betriebssystem passend aufbereitet.” sollte man ueberdenken und besser nur Dateinamen zulassen, die jedes OS versteht. -
@hein-bloed sagte: Gute Idee, diesen Hinweis zur Beruecksichtigung bei neuen Versionen an die Entwickler zu geben. Die Funktion “Die Dateinamen werden für jedes Betriebssystem passend aufbereitet.” sollte man ueberdenken und besser nur Dateinamen zulassen, die jedes OS versteht.
Das würde dann von vielen Usern – aus Erfahrung – wieder als Einschränkung empfunden werden. Die meisten User arbeiten nur auf einem OS, deshalb ist die aktuelle Implementation sehr wohl sinnvoll. Und andere lernen sehr schnell, welche Zeichen zu vermeiden sind.
Im Gegensatz zu dem, was @MenchenSued sagt, kann man ja sehr wohl selbst testen, wie MV sich beim manuellen Editieren des Dateinamens verhält (dazu braucht man keinen Entwickler, die das – abgesehen von @xaver – eh nicht auswendig wüssten). Und genau eine solche Erfahrung hat du ja beschrieben.
Wenn ich unter macOS im MV-Speicherndialog ein unter dem eigenen OS verbotenes Zeichen (z.B. “:” oder “.” zu Beginn) manuell einfüge, dann warnt mich MV, indem das ganze Eingabefeld rot wird. Wenn ich dann trotz der Warnung das Zeichen nicht wieder lösche, sehe ich, dass bei der heruntergeladenen Datei trotzdem das verbotene Zeichen ersetzt wurde (im Beispiel: “:” --> “/”; der Punkt zu Beginn wird von MV ignoriert). Womit gezeigt wurde, wie die Ersetzungstabelle funktioniert und wann sie zum Einsatz kommt…
@hein-bloed sagte: Wenn man den Dateinamen vor dem Download aendert, kannt man nach der file extension (z.B. .mp4) versehentlich noch ein Leerzeichen eingeben. Das passiert sehr leicht beim copy & paste. Linux interessiert das ueberhaupt nicht - der spielt das file ohne zu murren, aber wenn man die Datei unter Windoof abspielen willst, weiss es damit nix anzufangen.
Dein Problem hat nichts mit “Pausenchecks” und letztlich auch nichts mit MV zu tun, sondern ist im Falle des Leerschlags nach der Dateiendung eine Einschränkung (by Design) dieses beschränkten Betriebssystems mit dem Namen Windows. Das Problem hast du ja auch, wenn du in einem Dateimanager unter Linux ein unter Windows verbotenes Zeichen setzt.
-
@styroll Wir wissen ja um das Problem. Ich bin halt der Meinung, dass Dateinamen, die von allen OS verstanden werden, die beste Loesung ist. Auch Linux-freaks kommen mal in die Situation, dass sie Windoof-usern Filme ueberlassen wollen.
Dieser thread war als Hinweis gedacht. Entscheiden ueber die Implementierung will und kann ich nicht. -
@hein-bloed sagte: Dieser thread war als Hinweis gedacht.
Das ist schon klar und auch völlig ok, auch wenn es etwas merkwürdig ist, dass du weder einen Bitte noch eine Frage stellst (@MenchenSued musste dir sogar eine Frage unterstellen). Meine Antwort was genauso nur ein Hinweis.
@hein-bloed sagte: Wir wissen ja um das Problem. […] Auch Linux-freaks kommen mal in die Situation, dass sie Windoof-usern Filme ueberlassen wollen.
Nochmals: Warnt dich dein Dateimanager unter Linux, wenn du ein “?” bei einem Dateinamen tippst? Falls “nein”, bin ich mir nicht so sicher, ob wir vom gleichen Problem sprechen…
Zudem kannst du mit der Ersetzungstabelle ja deinem Wunsch entsprechen, “?” zu ersetzen (das funktioniert wenigstens für Dateinamen mit “?” im Originalnamen, nicht jedoch für “?”, die getippt oder gepastet wurden). Du kannst auch nur ASCII-Zeichen erlauben…
Evtl. passt du den Zieldateinamen (z.B. “%t-%T.%S”) im Speichern-Set so an, dass ein Copy&Paste gar nicht mehr nötig ist.
Evtl. könnten die Entwickler verhindern, dass ein Leerzeichen nach der Dateiendung geschrieben wird (das macht nämlich im Unterscheid zu einem “?” bei keinem OS Sinn). Allerdings ist es mir nicht klar, wie überhaupt beim Copy&Paste an dieser Stelle ein Leerschlag entstehen kann. Vielleicht erklärst du uns das noch…
-
@styroll sagte in Plausibilitaetscheck fuer geaenderten Dateinamen:
Allerdings ist es mir nicht klar, wie überhaupt beim Copy&Paste an dieser Stelle ein Leerschlag entstehen kann. Vielleicht erklärst du uns das noch…
Vor dem Kopieren muss erst etwas markiert werden. Da passiert es schnell mal, dass da unbemerkt mehr markiert wird, als gewünscht. Insbesondere im Browser passiert so etwas relativ häufig. Und nein, das ist nicht immer deutlich anhand der Markierung sichtbar. Ich habe da schon oft über mit kopierte Leerzeichen und Tabs am Anfang und Ende geflucht.
-
@mvsfsvm sagte: Vor dem Kopieren muss erst etwas markiert werden. Da passiert es schnell mal, dass da unbemerkt mehr markiert wird, als gewünscht.
Da hast du schon recht. Ich beziehe mich aber ganz auf den konkreten Fall. Man kopiert in der Praxis keine Dateiendungen aus dem Browser ins Speichern-Dialogfenster von MV. D.h. vor der Dateiendung könnten allenfalls ungewollte Zeichen mitkopiert werden, wie danach ein Leerzeichen durch Copy&Paste auftauchen kann, erschliesst sich mir immer noch nicht…
-
Dass nur die Dateierweiterung per Copy & Paste in den Datei-Speichern-Dialog wandert, davon war bisher hier im Thread aber nicht die Rede. Außerdem kommt es bei der Frage, ob nach der Dateierweiterung etwas ungewollt mit kopiert werden kann, doch wohl darauf an, wo die Dateierweiterung markiert und kopiert wurde.
-
@mvsfsvm sagte: Dass nur die Dateierweiterung per Copy & Paste in den Datei-Speichern-Dialog wandert, davon war bisher hier im Thread aber nicht die Rede.
Ja, das ist richtig. Der OP schreibt sogar überhaupt nichts davon:
@Hein-Bloed sagte: Wenn man den Dateinamen vor dem Download aendert, kannt man nach der file extension (z.B. .mp4) versehentlich noch ein Leerzeichen eingeben. Das passiert sehr leicht beim copy & paste
Sein Problem kann nur entstehen, wenn man mutwillig etwas nach der Dateiendung hineinkopiert (was keinen Sinn ergibt) oder wenn man aus einem Text (Webseite) einen Dateinamen mit Dateiendung und folgendem Leerzeichen kopiert und einfügt (wo soll dieser Fall auftreten und was ist dessen Sinn?)…
-
Die Problembeschreibung des Threadstarters ist etwas unglücklich ausgefallen. Da ist das Copy & Paste als Beispiel genannt. Wie du so schön erkannt hast, tritt das Problem eigentlich nur bei Benutzung von Copy & Paste auf.
Einen Sinn gibt es nicht, denn das erfolgt doch unbeabsichtigt und bleibt mitunter unbemerkt.
Wo das Problem auftreten kann, wurde schon beschrieben.
-
@mvsfsvm Ich glaube, wir reden hier alle etwas aneinander vorbei. Ganz konkret: Ich sammle u.a. die Folgen der ‘Eisenbahn-Romantik’. Die Datei wird vom MV gespeichert nur mit dem Titel der Sendung (z.B. Bahndampf in Niederwunsen) und der Endung. Ich kopiere den Namen aus dem Feld ‘Dateiname’ im Fenster ‘Download editieren’ (dort steht der Dateiname bereits mit angewendeter Ersetzungstabelle) in eine ods-Tabelle und setze die Folgen-Nr und das Datum voran. Das sieht dann so aus: 412 - 2017_11_09 - Bahndampf in Niederwunsen. In der Tabelle gibt es auch ein Feld, in dem der Dateiname steht (als link, um den Film direkt aus der Tabelle zu starten). Dorthin kopiere ich dann den o.g. Dateinamen und ergaenze die Endung .mp4. Dieser Dateiname wandert dann wieder per copy&paste zurueck in das Feld ‘Dateiname’ im Fenster ‘Download editieren’. Dabei passiert es eben manchmal, dass sich ein Leerzeichen hinter der Dateiendung einschleicht. Und die Ersetzungstabelle wird danach nicht mehr angewendet.
Mein Thread war nicht als bug-Report gedacht sondern nur als Hinweis, dass dort entweder keine Plausibilitaetskontrolle mehr stattfindet, oder eben entschieden wird: Linux hat damit kein Problem, lassen wir so. -
Also ich finde man kann es ruhig einführen dass Leerzeichen bei Pfaden am Anfang und am Ende weggetrimmt werden, dann treten solche Fehler halt einfach nicht auf. Es ist dann auch egal wenn es nur 0,01% der User mal betrifft.
