Just try a test library without the \\?\ prefix. I don’t think this was ever tested with local assets.
2 Likes
Plex for Windows is a player, I was not referring to Plex Media Server.
Still, I’m on Windows 10 20H2, with Windows Update always on.
I had a working library without the \\?\ for over a year now, except I suddenly found out there were some files (with long paths) missing from it, than I had to search these forums for a fix. Until Plex enables longPathAware in it’s application manifest, this prefix seems to be the only way to ensure Plex gets every file from my folder (by the way, my folder structure and filenames are automatically managed by Sonarr, so I don’t even have a way to notice those missing files because they aren’t manually added).
My suggestion in the other thread was to TEST the \\?\ prefix, not a promise that it would work. 
(If part of the problem is Sonarr generating too-long paths, there have been recent changes to Sonarr for that. Are you up-to-date? You could also switch Sonarr to use a shorter naming scheme.)
Yes, I understood that it was untested. It works, the only thing is that it pops another bug. As you explained, this whole prefix workaround wouldn’t even be necessary if Plex simply included longPathAware.
Sonarr is up-to-date, it’s v3 and set to auto-update. The paths are long indeed, but that only happens either because of a long episode name, or because I use DVD orders which sometimes group up to 5 episodes in a single file (which generates a very long filename).
Regardless, I have Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled enabled, so it’s not a problem anywhere else in my setup, except for the present issue.
So right now, I have to choose which is the worst compromise: maiming my naming scheme (and dealing with other nuisances) or manually uploading the subtitles every time I watch something.
For the time being, I’m doing the latter, in the hopes the issue can be fixed or that Plex at least includes fixing longPathAware in it’s roadmap. If neither can be done, well, there will be a lot of bad alternatives to consider.
It works, except it doesn’t.
I personally don’t find the Episode Title adds much value to filenames. Plex doesn’t use it for matching. I rarely interact with files in the filesystem directly, and when I do, I move entire seasons, not individual files. And Sonarr can batch rename your files if you change the naming scheme.
Did you try the test @OttoKerner asked for? Can you test again, perhaps a new test library, with a copy of these same files, without the \\?\ prefix, just to confirm that’s the issue?
It does what it’s intended for: media files that were missing from the library without the prefix are now being picked up, the problem lies only with the srt files.
Sadly, I do. That would be one of the nuisances, compromising on that would be one of the bad alternatives, although a likely one.
I believe my previous answer assessed that. Before I had the \\?\ prefix, this library did not have this issue, it popped up precisely when I introduced it, which makes it the cause for sure.
My whole point here is that I’d rather try to solve the problem this workaround generates (and hoping it won’t be needed anymore in a near future) than going machete on my files from the start.
Fair enough. That test is being requested to confirm that the prefix is the issue, and to rule out anything else, potentially unknown, that might be interfering. It’s boring and possibly redundant, but is standard troubleshooting practice.
I’m wondering if the prefix is causing problems at playback, when the subs are requested by the player.
If you’re confident the prefix is the issue, don’t want to test, and don’t want to change your naming scheme, then you’re kinda at an impasse.
Did you vote on the request for long file path support?
On the contrary, what I’m saying is that this test had already been done and the result is positive, the prefix is the problem!
But for redundancy’s sake, I created a new library with the exact same files, this time without the prefix. As expected, the subtitles worked again. (And I should add that I switched to my movies library to help rule out the écharacter and folder structure issues, so I’m not getting missing files, but that’s because my files with long paths are in another library).
Ok, so I’m closing this thread. I just changed my naming scheme and ran into the problems I was talking about, but I just figured that I’d rather deal with that than solving this issue, so I won’t be investigating this matter anymore, thanks.
I just tested this and I was able to see my local subtitles using the \\?\ prefix. Not sure what’s going on for you.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
