All Activity

Hello Emby team, I am experiencing a PathTooLongException when Emby scans a media library on Linux. After investigating the issue, I found a previous Emby community thread that appears to be very similar to my case: Docker/Fedora 41 - Too long path error (actually it's not) https://emby.media/community/topic/137639-dockerfedora-41-too-long-path-error-actually-its-not/ My environment: Emby Server: 4.10.0.40 OS: Linux .NET: 8.0.28 Docker deployment Architecture: x86_64 The error is: System.IO.PathTooLongException: The path '/115_media/Media Library/GHS Media/Normal/雄神YUU' is too long, or a component of the specified path is too long. at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext() at System.Collections.Generic.LargeArrayBuilder`1.AddRange(IEnumerable`1 items) at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source) at Emby.Server.Implementations.IO.ManagedFileSystem.EnumerateFileSystemInfos(...) at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileSystemEntries(...) at MediaBrowser.Controller.Providers.DirectoryService.GetFileSystemEntriesInternal(...) What makes this interesting is that Linux itself can access the directory normally. For example, inside the Emby container: ls -la "/115_media/Media Library/GHS Media/Normal/雄神YUU" works correctly and lists the files. The problem appears to be related to the length of individual filenames rather than the total Linux filesystem path. I measured the UTF-8 byte length of the .strm filenames and found many filenames between approximately 400 and 687 bytes. For example: 687 bytes 679 bytes 677 bytes 675 bytes ... The filenames contain a large amount of Chinese/other non-ASCII Unicode characters. The previous community thread mentioned above appears to have found that truncating filenames to approximately 255 bytes avoids the problem. However, renaming the files is not a practical solution for my setup. These are automatically generated .strm files and changing their filenames would affect my existing media library/NFO matching. My question is: Is this still a known limitation/bug in the Linux version of Emby? More specifically: Is there a recommended workaround that does not require renaming the files? Has this issue been fixed or changed in a newer Emby version? Could Emby handle this exception during directory enumeration so that files with long UTF-8 filenames do not prevent the rest of the directory from being scanned? Is there a plan to support filenames longer than approximately 255 UTF-8 bytes on Linux? The fact that Linux can enumerate the files normally with ls, while Emby's .NET System.IO.Enumeration.FileSystemEnumerator throws PathTooLongException, makes me suspect this is related to the .NET/Emby filesystem enumeration layer rather than an actual Linux filesystem path limitation. Any guidance from the development team would be greatly appreciated. Thank you.

Hi Luke, Thanks for following up. Yes, I'm still having the issue and I've tried a few different things to see if that would work with no luck. My Emby server is on 4.10.0.40, iOS app is 2.2.58. I run the server on a Synology 1621+, so I tried new servers on Ubuntu & Windows. No music would play through the iOS app, but could play music through my browser. Tried installing Netbird rather than Tailscale. Same results. Tried moving the music location from the Synology server to locally on Windows. Nothing still. Lastly, tried accessing my Emby server through jellybox rather than the Emby app and wasn't successful there either. So I've run out of ideas pretty much at this stage, unless there is something with the phone itself.

Where is that setting? Haven’t changed anything one way or another since I upgraded.

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

I upgraded to 4.10 yesterday and seeing the same issue with the sidebar disappearing in Edge, just like OP I have to hit refresh to get it to come back. I am also occasionally getting the admin dashboard on top of the home screen when clicking the gear icon. @LukeHere is a screenshot mate, when you hit the gear icon it goes back to admin with no side panel, hitting the sidebar icon slides out a blank panel.

Well, Spotlight and slideshow fixes are much more important, didn't you know?

Started testing in May 2020 far as I can see. Impressive, no ?

4 years and nothing to show for it

Annoying, very. I've been trying to get it to go back to the beginning as well just now, and failed. I also have the impression it has got better for me recently. I used to go through my movies looking for duplicates and deleting any I didn't want or match poster images so that say 4K versions had the same image as 1080p posters, and backing out from there back to my movies I would regularly end up back at the very first one. But as I say seems, repeat seems better lately. Obviously still 'giggling' away though. Must admit, when I said pattern, I was thinking more found reproducible steps, not happens fairly often.

Yes that's more or less what I'm talking about. Mine looks much faster though. Really? 1 out every 4 clicks from the details page back to library list is not a pattern? That means every 4th( or so) movie/show I look at I have to scroll all the way back to where I was on the list. I consider that very annoying.

This appears when trying to delete a user. Value cannot be null. (Parameter 'ConnectServerId')

I guess that means not much of a pattern. Managed to get this - Emby jumping.mp4

The content type is video (movies). Version 4.8.11.0.

No, nothing I do fixes the issue. It just jumps to the top of the list and it goes away. Happens about 25% of the time when I go from the detail page back to the library list. Do I use custom CSS? Yes, but I only started doing that about year and half ago. I have been dealing with this issue for longer than that, but might be the cause. I don't know. I don't know if it's related to the issue other users have described. Going from the detail page to the library list sending them back to the top of the list, but it seems similar so I thought I would report it. (I also deal with this too, but as far as my own usage of the web app, that bug seems to have always been there. I guess I've just gotten used to it and expect that to happen.) The "jiggling" issue hasn't been going on as long as that one, but it's also not a "new" issue either. (Edited other posts after I realized I miss spelled jiggles as giggles)

Hi, can you guide me through this problem? How could I solve it?

Hi, have you checked what libraries are enabled on the continue watching section?

Looks much better with no gap at top. Haven't tried with EHS though. Minor nitpick with the time progress dots things - In Android app uses more of a line for some reason - whereas ATV app uses circle and looks nicer -

It's been a few years, just thought I'd ping this again. I have a library of short films, and it's kind of silly to have trailers play that may well be longer than the films.

Do you find you can (usually) stop it with the mouse wheel (if you have one) ? I've wondered if the css I use might cause it, but I've never checked, plus its to unpredictable - d'you use css ?

The range setting is nothing you can do anything about. It's just noise indirectly caused by the yuv420p format of the video. I should remove that from being logged.

I really struggled to find the word to use to describe what I see when this happens, but yes that is more or less what it does. Rows jiggle up and down rapidity super fast. When I click up or down (or use scroll wheel) the list jumps back to the top of list.

Jiggles then rebounds to the top.

Thanks. In further testing and playing around, I have discovered that a certain source folder within the audio book folder is the culprit. For whatever reason if that particular book is in the source, it makes the reference to the music library. So I have removed it, problem solved that direction. And just looked, it seems to have resolved issue the other way. Also, what was driving me kinda nutty was the fact that when I went into the "Various Artists" sub, and clicked on a song, the source for it was a folder that the AudioBook library should not even be looking at. Issue is resolved, that one book is not important, so I am leaving it offline.

New patch release - Version 4.1.5.0 Download .dll and full release notes: https://github.com/soderlund91/HomeScreenCompanion/releases/tag/v4.1.5.0 Updates, bugfixes and new logo Now also available in the official Emby plugin catalog! NEW LOGO IMPORTANT! Minimum required Emby server v4.10.0.40 Release notes Updates: Logo: New logo. I never really liked the old one.. (And yes, this is 110% AI generated) Top-list: Added option to NOT show a number on poster. Functionality is still the same Logging: Rehaul of the logging. Trying to make it simpler for the standard user to understand. Logging: Added option in settings to log what movies are missing from library when using external lists. Backup: Rehaul of the backup function to include more options. You can now also select what you want to download/upload. (Old backups will still work) Fixes: External lists: Fixed a bug where only one URL source was handled even though multiple URL where entered by the user. Top-list: Fixed a bug where the number sometime didn't get written on the poster/thumb HomeScreenCompanion.dll

Thanks for the clarification on the keywords and language codes. Just to confirm, the latest tests were already done with "eng" only—I had already removed both "fra" and "jpn" as well as the non-English keywords. Regarding the range warning (make sure you did set range correctly), I wasn't sure if that was a setting I had to configure on my end or just an internal FFmpeg warning. Those tests were run with QSV. I will run a short detection using CPU only as requested, test it again with hardware acceleration, and share the new logs.