Repository navigation
Normalize filename before storing #1027
Description
Playback position is saved in ~/.mpv/watch_later/* where * is the MD5 of the filename as it was passed to mpv. This is a problem if you launch mpv in different ways, that may use different representations of the same unicode filename.
For instance, dragging a japanese file from the Finder into a Terminal window on the Mac uses a different normal form than copypasting the filename, so playback will not resume.
The solution is converting all filenames to the same normal form (no matter which) before calculating the hash.
Activity
tewe commentedon Aug 21, 2014
I'm only talking about unicode, not relative paths. I don't see why the problem would be restricted to the Mac, but don't have other platforms to test on.
If you didn't like the Finder example, think about storing paths in a database. You're almost guaranteed to get a different unicode representation out than what you put in.
tewe commentedon Aug 21, 2014
It's the standard. As soon as you do any modifications to a filename you have to deal with it. I wouldn't be surprised if loading external subtitles had that bug as well, and aren't found despite the names looking identical.
Luckily the fix is probably two lines, but might add a dependency on something other than iconv. Also this stuff is a bitch to test across platforms.
tewe commentedon Aug 21, 2014
POSIX only specifies paths as byte strings. On Linux you can configure per user how unicode names are stored. But I'm sure you know this, since you already know that the bug is in OS X.
tewe commentedon Aug 21, 2014
Again, representations are part of the unicode standard. It's completely legal to use different ones. A user might even type different ones into the shell. You have to deal with that, or only support ASCII.
qmega commentedon Aug 21, 2014
FWIW, I don't have any problems with Japanese filenames in terminal vs. file manager under KDE on Linux. Starting from either and resuming from the other works fine.
If I explicitly convert one to decomposed form and pass that to mpv, it can't even find the file. Which kind of makes sense, because under POSIX with byte-string paths I could theoretically have two different files with different normalizations of the same unicode string.
Also, it doesn't really make sense to allow any "K" form, as that for example converts "／" (completely legal in a filename) to "/", which would then point to a completely different path. That introduces ambiguity even if unicode is handled at the filesystem level.
tewe commentedon Aug 21, 2014
That looks like a terrible idea. You could never type a filename, because you don't know where the existing file comes from, and if its form matches what your input method produces. But if it has to be supported...
qmega commentedon Aug 21, 2014
Yes, of course it's a terrible idea; I'd never actually do it. But POSIX allows it, so POSIX-compatible filesystem APIs have to treat those strings as different. That particular case isn't "supported" on purpose, it just happens to be possible. A more realistic example would be a filename that isn't valid UTF-8 at all. I guess Apple's filesystems do require proper Unicode filenames, which would allow them to do conversion safely, but in doing that, they break POSIX.
Pacoup commentedon Aug 22, 2014
@wm4 So, out curiosity, are you saying even if someone were to go out of their way and implement this code you wouldn't accept it?
qmega commentedon Feb 4, 2015
Just had an idea: Why not do the conversion before calling mpv, so mpv doesn't have to care? Try adding something like this to your path before mpv:
That's assuming Finder uses NFD and Terminal uses NFC. If it's the other way around, change the first argument to normalize().