Jump to content

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


letterman
Go to solution Solved by softworkz,

Recommended Posts

letterman

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 by letterman
Link to comment
Share on other sites

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

Link to comment
Share on other sites

letterman

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 by letterman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

rbjtech

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

rbjtech

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

letterman

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

Link to comment
Share on other sites

rbjtech

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) 

 

 

  • Like 1
Link to comment
Share on other sites

letterman

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.

Link to comment
Share on other sites

letterman
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

 

Link to comment
Share on other sites

rbjtech
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.   

Link to comment
Share on other sites

letterman

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.

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
  • Solution

@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.

  • Thanks 1
Link to comment
Share on other sites

rbjtech

 @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.

 

 

Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

Painkiller8818

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

rbjtech

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 by rbjtech
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...