All Activity

Thank you it worked. But unfortunately it only worked once with the app. In a second run the app does not connect properly anymore. I can gladly share a photo later on. My workaround is using emby with the https address over the internet browser now. That works fine, but I have to controll with a mouse cursor via tv remote.

Emby Server version: 4.8.10.0 Operating system: Linux (Ubuntu 22.04, kernel 5.15.0-130-generic) .NET Runtime: 6.0.31 Installation type: Native .deb package Issue: I'm unable to delete certain users from the web dashboard. The following error is logged when the delete request fails: System.ArgumentNullException: System.ArgumentNullException: Value cannot be null. (Parameter 'ConnectServerId') at Emby.Server.Connect.ConnectManager.CancelAuthorizationByConnectUserId(String connectUserId) at Emby.Server.Connect.ConnectManager.RemoveConnect(User user, String connectUserId) at Emby.Server.Implementations.Library.UserManager.DeleteUser(User user) at Emby.Server.Implementations.Services.ServiceController.GetTaskResult(Task task) at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, ReadOnlyMemory`1 urlString, ReadOnlyMemory`1 localPath, CancellationToken cancellationToken) Source: Emby.Server.Connect TargetSite: Void MoveNext()

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.