Path Length Character Limit: Try Using the Volume ID

[SideCar 4]

FYI: for those of you still having trouble with metadata on files with long path names even when using the UNC path (e.g. - \\?\C:\...) there is another potential solution.

I've discovered that pointing the library to a fully-qualified UNC path using the unique volume ID instead of the drive letter (e.g. - \\?\Volume{aab78429-72f5-4788-8931-acad196c2835}\...) seems to solve all of the issues related to long path names.

In my case, specifying a UNC path took care of the issues with ffprobe grabbing metadata from audiobook files with long titles but it still left a problem with ffmpeg not pulling the embedded cover art. Pointing to the volume ID cures the ills of both ffprobe and ffmpeg and gets all of the embedded metadata into Emby.

This even works for volumes mounted on an NTFS folder instead of a drive letter which makes it very useful for large installs with lots of disks. I've been running my libraries with this path convention for several days now without any sign of problems.

There are several ways to get the unique volume ID. The easiest, IMHO, is to just open a PowerShell window and issue 'get-volume | select filesystemlabel,uniqueid'. That should give you all of the info you need.

Hope this helps out others as well.

Cheers.

[Luke 42085]

Thanks for the tip.

[letterman 40]

Nice idea. UNC >257 characters is still a problem with ffprobe.

In case, I change all my paths to the new path with a unique volume ID: What will happen, if I need to change to whole harddisk, e.g due to technical problems? There will be a new unique volume ID. Right? 
I have two large HDDs and >20 libraries. Do I have to change each path in emby afterwards?

And what about playlists:
the PlaylistItems are still defined with the full path within the XML-File. This is already a problem, where I don't know how to help myself in case of path changes, but to adjust this manually.

Edited June 18, 2022 by letterman

[Luke 42085]

5 hours ago, letterman said:

Nice idea. UNC >257 characters is still a problem with ffprobe.

In case, I change all my paths to the new path with a unique volume ID: What will happen, if I need to change to whole harddisk, e.g due to technical problems? There will be a new unique volume ID. Right? 
I have two large HDDs and >20 libraries. Do I have to change each path in emby afterwards?

And what about playlists:
the PlaylistItems are still defined with the full path within the XML-File. This is already a problem, where I don't know how to help myself in case of path changes, but to adjust this manually.

Hi, I'm not really sure what you're asking. Can you please describe your questions in more detail? Thanks.

[letterman 40]

1) @SideCar suggested a way  pointing the library to a fully-qualified UNC path using the unique(!!!) volume ID instead of the drive letter (e.g. - \\?\Volume{aab78429-72f5-4788-8931-acad196c2835}  I asked what will happen, if the corresponding HDD has to be replaced. Will there be a new unique ID? What effect would a new ID have to the emby-libraries?

2) Playlists: Emby uses the full path of the songs within the XML-File. E.g. 

    <PlaylistItem>
      <Path>M:\Music_Test\[New Age] Dieter Meyer - Best Of\02. Clouds.mp3</Path>
    </PlaylistItem>

@SideCarAs suggested, if the library points to something like e.g. - \\?\Volume{aab78429-72f5-4788-8931-acad196c2835}  instead of e.g. M:\ all the .XML-Playlists files are connected to this unique ID or am I misunderstanding something here?

[SideCar 4]

Windows assigns a unique volume ID whenever a new volume is created so yes, if you replace a disk all of the new volumes on the new disk will have a new volume id.

(Note that it's possible to change a volume ID for things like emergency recovery operations but anybody who does it without knowing what they're doing deserves the resulting pain. Don't try this at home.)

If you do have to replace a disk you will, therefore, need to go into the library settings in Emby, add a path to the folders on the new disk using the new volume ID, and then delete the old folder path to the old volume ID. After that Emby should be able to deal with the change with a simply media scan.

As for playlists, that's something for Luke to answer as I don't use them. In theory, all Windows applications should be able to properly handle any of three types of volume mount points (drive letter, mounted folder, or GUID) and use/recognize all of them interchangeably. In practice, very few developers bother to build that capability into their code and a lot of applications break when fed a volume ID.

If Emby is using the hard path in the playlist files rather than a pointer to the library location then using the volume ID will probably break the playlists. I'm hoping that Emby has a mechanism to auto-update the file paths in playlists when the path to the library/media changes but, again, that's a question that Luke will have to answer.