Problem long paths/long filename (>259 characters) / ffprobe error

[letterman 40]

Emby Server 4.5.2.0
Windows 10 - Version 2004 - Long path enabled in policy & registry.
Long filename usage works in e.g. in Total Commander & VLC-player

Hi!

emby does not playback songs in paths >259 characters, even they are shown (but not tagged) in the library.

Problem may be ffprobe. log-file: 'Error App: Error in ffprobe'

I tried to use \Emby-Server\system\ffprobe.exe manually in command line. The error also appears. 
"No such file or directory"

What is the solution to solve this problem?

Do I have to change/install another version of ffprobe? How?

Best, Stefan


PS:

This guy may have the same problem, but the solution does not work with emby i think
https://stackoverflow.com/questions/63243711/ffprobe-file-not-fournd-error-due-long-path-but-windows-long-path-enabled

Log Playback long paths not possible _ embyserver.txt.txt

Edited November 6, 2020 by letterman

[Carlo 4484]

Hi, The obvious simple solution  would be to shorten the library paths so they will never go over 256 characters.

[letterman 40]

This is of course the "simplest" solution, but not possible due to the amount of data. Is there no alternative? Am I the only Windows user who has this problem?

 

Edited November 6, 2020 by letterman

[ebr 15438]

That is likely to be the only solution since this would be an OS or file system limitation that we would not have much control over.

[rbjtech 4816]

The issue is with ffprobe - Both Windows and Emby and handling your long paths ok (or they would not be in the database).  

[Carlo 4484]

1 minute ago, letterman said:

This is of course the "simplest" solution, but not possible due to the amount of data. Is there no alternative? Am I the only Windows user who has this problem?

 

Can you give us a couple of examples of you current disc layout?  Maybe we can make suggestions for you.

[rbjtech 4816]

It 'may' be possible to use Symlinks to shorten the long file path - but it's messy and may end in tears.

[ebr 15438]

1 minute ago, rbjtech said:

The issue is with ffprobe

Ah, okay.  Then perhaps it is something that can be reported to them.  However, the near term solution is probably going to be to modify the paths.

[letterman 40]

So, no alternative but shorting file path. Very unhappy,  back to stone age. Actually, I used emby on a home QNAP 251 for 2 years without any path-problems (of course), but it is much to slow. My worst 5 years old windows system is x-times faster and runs very speedy....  one problem solved, a new huge one added

[letterman 40]

who is responsible for ffprobe? I think these programmers need to update the software. http://ffmpeg.org/?

Edited November 6, 2020 by letterman

[rbjtech 4816]

As you appear to be the first to hit this issue - perhaps rather than going down the route of asking for a software modification (which, with respect is not going to happen quickly..), why not fix the source of the issue ?  Having a path this long must be an absolute nightmare to manage and I suspect you are trying to organise files by file structure, rather than let metadata and a database do it for you.  That's why @cayars asked to see an example.

'UNC Shares' may also be an alternative to keep things more manageable.

For example

c:\grgdfgddfhghkgkhgh\g\kgkgkgkgkg\kg\kggkgkgk\gk\kgkgkg\\files1\kgkgkgkgk\klhkhikhiuguigyigigiygiy\yigigigigig\igigigigi\igigigigigig\igigigigi\gi\g\igi\files2

Can simply be shared as '\\computername\files2' at the very top level or \\computername\files1 at a much lower level as required, thus sharing all files 'above' it (but effectively halving the file path length) 

 

 

[letterman 40]

You are right. I am somehow a little bit old fashioned. I have perfect metadata (and tag a lot, too) and love emby. But besides that I love organising my files by folder structure with music style-artist-composer-meaningful titlename and so on. Of course, the paths are long. from exprecience about 300 to 700 characters incl. filename. The advantage is, in addition to emby I can browse by filestructure, too. It gives me & my friends (who sometimes do not use emby) a good orientation. That's why shortening is such a problem. and - by the way - only windows-filemanagement is the problem. Hope it will be solved someday. I know, the software modification will not be done just because of me, but I am sure, that there are lots of users how think the way I do.

[Luke 38847]

The issue appears to be in ffmpeg, not emby.

[letterman 40]

Quote

c:\grgdfgddfhghkgkhgh\g\kgkgkgkgkg\kg\kggkgkgk\gk\kgkgkg\\files1\kgkgkgkgk\klhkhikhiuguigyigigiygiy\yigigigigig\igigigigi\igigigigigig\igigigigi\gi\g\igi\files2

Can simply be shared as '\\computername\files2' at the very top level or \\computername\files1 at a much lower level as required, thus sharing all files 'above' it (but effectively halving the file path length) 

Thanks for this advice, too. But my problems are not the main-levels, but the ALBUMNAMES and the FILENAMES itself, unfortunately

 

[rbjtech 4816]

1 hour ago, letterman said:

You are right. I am somehow a little bit old fashioned. I have perfect metadata (and tag a lot, too) and love emby. But besides that I love organising my files by folder structure with music style-artist-composer-meaningful titlename and so on. Of course, the paths are long. from exprecience about 300 to 700 characters incl. filename. The advantage is, in addition to emby I can browse by filestructure, too. It gives me & my friends (who sometimes do not use emby) a good orientation. That's why shortening is such a problem. and - by the way - only windows-filemanagement is the problem. Hope it will be solved someday. I know, the software modification will not be done just because of me, but I am sure, that there are lots of users how think the way I do.

I see where you are coming from, we have all been there in the early days of starting a media collection - it seems such a great idea at the time  - but the power of a searchable 'database' reading metadata 'tags' will far outweigh any file structure no matter how good it is - in terms of search speed, visibility and functionality.   

[letterman 40]

I do know that - but I hope you understand, that it is somehow a fictures problem. Windows 10 supports long paths >259 since anniversary update, only ffprobe isn't adjustedt yet. Everybody should be able to work the way he likes it. pro and cons are on both sides. And why isn't it the best to take them all? I would like to do so.

 

[ebr 15438]

Just now, letterman said:

I do know that - but I hope you understand, that it is somehow a fictures problem. Windows 10 supports long paths >259 since anniversary update, only ffprobe isn't adjustedt yet. Everybody should be able to work the way he likes it. pro and cons are on both sides. And why isn't it the best to take them all? I would like to do so.

 

Yes, but you need to make that case to the developers of ffmpeg/probe.  It being an open source project, even if someone takes it up it may take a while.

Therefore, the advice we're giving you is that your best solution is most likely going to be to modify the paths.

[letterman 40]

I know. Thanks a lot for all you do for emby

 

[softworkz 4296]

@letterman - I'm afraid, but most of what has been said here is wrong.

When you add a library folder to Emby, you need to add the "magic prefix" \\?\ and your dreams will become true.

 

That means, when you media is under c:\mymedia

You'll add this folder as: \\?\c:\mymedia

 

ffmpeg and ffprobe can deal with it. 

 

Disclaimer: We can't guarantee that it will work everywhere in Emby. It is basically working, but you may encounter situations where you could run into problems.
Also, you need to have at least Windows 10, version 1607 for this to work.

[rbjtech 4816]

 @softworkz

So are you saying ffmpeg/ffprobe are not the issue here ?

Can you expand on what the 'magic prefix' does and where this is documented ?

Does it work with UNC? - would \\?\\servername\share work ?

Thanks.

 

 

[softworkz 4296]

1 hour ago, rbjtech said:

Does it work with UNC? - would \\?\\servername\share work ?

IIRC it's \\?\\UNC\servername\share

All this can be found in MS' Windows documentation. It's easy to find.

[softworkz 4296]

It's here: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

[Painkiller8818 217]

This is a general windows limitation, this is nothing emby or ffmpeg can fix. This is a Windows limitation for years and always will be like that.

[softworkz 4296]

4 minutes ago, Painkiller8818 said:

This is a general windows limitation, this is nothing emby or ffmpeg can fix. This is a Windows limitation for years and always will be like that.

What's this?

Didn't you read the last few posts?

[rbjtech 4816]

Thanks @softworkz - that is useful to know.  @cayars - this might be useful to be included in the wiki somewhere - perhaps in the library setup section ?

Edited December 11, 2020 by rbjtech