letterman 33 Posted November 6, 2020 Share Posted November 6, 2020 (edited) 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 thinkhttps://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 Link to comment Share on other sites More sharing options...
Carlo 4328 Posted November 6, 2020 Share Posted November 6, 2020 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 More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
ebr 14863 Posted November 6, 2020 Share Posted November 6, 2020 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 More sharing options...
rbjtech 4170 Posted November 6, 2020 Share Posted November 6, 2020 The issue is with ffprobe - Both Windows and Emby and handling your long paths ok (or they would not be in the database). 1 Link to comment Share on other sites More sharing options...
Carlo 4328 Posted November 6, 2020 Share Posted November 6, 2020 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 More sharing options...
rbjtech 4170 Posted November 6, 2020 Share Posted November 6, 2020 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 More sharing options...
ebr 14863 Posted November 6, 2020 Share Posted November 6, 2020 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 More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 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 More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 (edited) who is responsible for ffprobe? I think these programmers need to update the software. http://ffmpeg.org/? Edited November 6, 2020 by letterman Link to comment Share on other sites More sharing options...
rbjtech 4170 Posted November 6, 2020 Share Posted November 6, 2020 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) 1 Link to comment Share on other sites More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 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 More sharing options...
Luke 36888 Posted November 6, 2020 Share Posted November 6, 2020 The issue appears to be in ffmpeg, not emby. 1 Link to comment Share on other sites More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 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 More sharing options...
rbjtech 4170 Posted November 6, 2020 Share Posted November 6, 2020 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 More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 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 More sharing options...
ebr 14863 Posted November 6, 2020 Share Posted November 6, 2020 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. 1 Link to comment Share on other sites More sharing options...
letterman 33 Posted November 6, 2020 Author Share Posted November 6, 2020 I know. Thanks a lot for all you do for emby Link to comment Share on other sites More sharing options...
Solution softworkz 3301 Posted December 11, 2020 Solution Share Posted December 11, 2020 @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. 1 Link to comment Share on other sites More sharing options...
rbjtech 4170 Posted December 11, 2020 Share Posted December 11, 2020 @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 More sharing options...
softworkz 3301 Posted December 11, 2020 Share Posted December 11, 2020 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. 1 Link to comment Share on other sites More sharing options...
softworkz 3301 Posted December 11, 2020 Share Posted December 11, 2020 It's here: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation Link to comment Share on other sites More sharing options...
Painkiller8818 203 Posted December 11, 2020 Share Posted December 11, 2020 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 More sharing options...
softworkz 3301 Posted December 11, 2020 Share Posted December 11, 2020 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 More sharing options...
rbjtech 4170 Posted December 11, 2020 Share Posted December 11, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now