All Activity

Summary Emby Server running on NVIDIA Shield TV Pro (2019) accumulates SMB/CIFS connections to a network-attached SMB share over time, without releasing them. Once the connection count reaches several hundred, the NAS (WD My Cloud EX2 Ultra) becomes fully unresponsive due to load, requiring a hard power cycle to recover. This has caused two separate NAS-side crashes within roughly one hour of normal media playback usage and several more since I installed emby Server on my ShieldTV. Note: I have another emby server running on my MyCloudEX2 for years running without any single problem. I just wanted to switch to a newer .NET System instead of mono. Environment Emby Server version: 4.9.5.0 Device: NVIDIA Shield TV Pro (2019), Tegra X1+ Android-Version: 11 Build-ID: RQ1A.210105.003.7825230_4387.0822 NAS / SMB Server: WD MyCloud EX2 Ultra, MyCloud OS 5, Samba (smbd) Network: Gigabit Ethernet, local network only (no remote access) Library storage: SMB share (smb://<NAS-IP>/...), accessed via mapped/attached network storage in Emby Steps to Reproduce Set up Emby Server on Shield TV with library folders pointing to an SMB share on a separate NAS. Use the server normally over an extended period (library scans, browsing, video playback) — no unusual or heavy load, single concurrent stream. Periodically check the number of active SMB connections from the Shield's IP address on the NAS side: netstat -an | grep :445 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn Observe that the connection count from the Shield's IP grows continuously over hours/days, rather than staying stable at a low number (1-5). Observed Behavior At the time of the crash, 393 out of 397 total SMB connections on the NAS originated from the single Shield device running Emby Server. This coincided with the NAS Linux kernel load average spiking to over 400 (on a 2-core system), with dozens of smbd worker processes stuck in uninterruptible sleep (D state), waiting on I/O. The NAS's web dashboard, and eventually most background services (Apache/httpd, nasAdmin, monit), became unresponsive. SSH access remained marginally functional but was severely lagged. Restarting Emby Server on the Shield (via its own web interface restart function, without touching the NAS) immediately dropped the SMB connection count from 393 to 0, and the NAS load began recovering. This is reproducible: the connection count was independently confirmed via netstat before and after the Emby restart, isolating Emby Server (and not any other NAS-side process) as the source of the accumulated connections. Expected Behavior Emby Server's SMB client should reuse or properly close SMB connections/sessions after file operations (metadata reads, thumbnail loads, playback) complete, keeping the connection count to the NAS low and stable regardless of how long the server has been running or how many files have been scanned/played. Additional Notes No equivalent SMB connection accumulation was observed when running Emby Server directly on the NAS itself (WD My Cloud "Emby Server" app, Mono-based build) accessing local storage — this issue appears specific to the Android TV client/server's SMB implementation when accessing a remote SMB share. There is no user-facing setting within Emby Server for Android TV to control SMB connection pooling, reuse, timeout, or maximum concurrent connections. This is a serious issue beyond cosmetic/performance concerns: it results in total NAS unavailability requiring a hard power cycle, affecting all other devices/services relying on that NAS (other Emby libraries, other network clients), not just Emby itself. Suggested root cause area Possibly related to how the Android TV media probe / file streaming layer (MediaProbeManager, ffprobe file access via local loopback Items/File proxying seen in server logs) or the underlying SMB/CIFS client library opens a new connection/session per file access request instead of reusing an existing pooled connection to the same share/host. Best regards Ingmar embyserver-63921908969.txt embyserver-63921916800.txt embyserver-63921922586.txt

Their potentially is as you could be giving HA complete and utter access to your devices with potentially zero oversight. Granting this access could potentially open you up to an unknown vulnerability which could allow an attacker to gain unfettered access to your devices and your home network. The fact you don't seem to understand the implications is mind numbing. It's like saying "Can i link my back door and my front door together so that when I open one the other does as well" while not knowing who, or if anyone is probing the door in an attempt to get in. This is not something I would ever allow. You're free to try it on your own, but it is obviously something the dev team would not condone, nor help you with. If your system becomes compromised, it's 100% on you. There is zero real world need for this. You're 100% on your own for this.

So after 2 additional updates (26.0.1 and 26.0.2) the folders still look like this (version 26.0.1 added bigger radius to the corners). Is this the new look by design? It seems inconsistent with the rest of the UI and looked correct back on version 4.9.5.13. Here is the web client example (Server 4.9.5.0): Here is the iPhone example (iOS 2.2.56): Here is the iPad example (iOS 2.2.55): If this is by design then I'll closed this issue.

Emby Windows app start up time 10sec Moonfin Windows app start up time 0sec.

Still hoping for option for details screen to look similar to spotlight (everything moved down out of backdrops way).

Ok so after some more testing I did run into a few queries that timed out, again mostly smaller/more common words, but it's MUCH less often than before. The small amount of timed out queries I ran into eventually worked if I retried them. Not sure if the recently searched list is affecting this, but it does take a while for that list to load, and will sometimes time out or will load after my search query. Still seems like the Emby process doesn't use as many threads/cores as is available on my 13600k when searching. The server does still seem to ramp up my fans and lock up during longer searches, though the amount of time it's locked has lessened noticably. I know how hard it can be fixing efficiencies when different users report different things, so thank you for the continued work on this. Looking forward to hearing from other users running on different hardware/platforms.

Oh. My app says 1.0.50.0 even after uninstalling and reinstalling.

There's a fix ready for this as well. Thanks again.

A fix is ready, hope it will be out soon. Thanks a lot for reporting!

There's a fix now (file picker) - I hope it will make its way into the next web app update.

@Luke Just to let you know the multiselect doesn't offer deletion either, night. Cheers, Bob

Just updated. Under Moonbase, I opened Emby dashboard, went to Moonfin down left hand side, and it opened on top of existing page, not instead of it. Need to f5 to tidy it up. Windows 11 on a 2560x1080 display.

thanks corrected, https://github.com/ginjaninja1/ListProtection

Trakt Air Dates Release Notes Version 5.0.6.0 Changes 5.0.6.0 Removed temporary diagnostic logging added while investigating an app connection issue 5.0.4.0 Fixed "Fetch is aborted" in the iOS app — Upcoming no longer makes clients wait on a slow Emby Reduced the wait for Emby's own Upcoming from 15 seconds to 5 before falling back Once Emby is seen stalling, the wait is skipped entirely for later clients until it recovers 5.0.2.0 Fixed apps reporting "unable to reach server" while browsers connected fine — the injected index.html response was dropping Emby's CORS and Private Network Access headers, which apps require and browsers don't All of Emby's response headers are now preserved when injecting TraktAirDates.dll

OK I have a question ! Strugling to clean my database (deleted everything until i figure out what works, I have no need for fancy page, so as my entire library is perfect , i am trying to go for minimal display. I prefer it is just music , select and hear it lol If i delete with mp3tag the tag for artists and scan a new library ,emby removes artists from its page. ( i am not talking for Now when I do the same with composers tag , emby keep displaying a Composers empty field. I have those enabled ALBUM,ALBUMARTIST,DISCNUMBER,GENRE,TITLE,TRACK,YEAR So why i have a composers field in emby, my library is just local nothing fetching from internet and just fetching the id3v2 tags.

26.0.2 Fix on now video tab not loading Update header style during video playback Improve new folder view style Update header style during video playback Fix new folder view style on apple devices Improve folder icon in folder views Various fixes related to submitted crash and error reports Support cancellation of initial connection process Add new spotlight home screen section option (requires Emby Server 4.10+)

Emby Web App Update: Version The Emby Web app has been updated to version Go and try out: https://app.emby.media/ Changes 26.0.2 Fix on now video tab not loading Update header style during video playback

sorry, now Added.

No file ?

Thanks Luke, Would be useful in future version Cheers, Bob NB Have you seen my other post re Media deletion, I've cleared 2.1TB and still getting DSM & Emby hangs, so frustrating.

Yes, is working. Thanks a lot.

OK so currently season level delete is not supported in this situation, so that's why you don't see the delete button. It's something that can be looked at in future updates. But you can easily mutli-select and delete several episodes at once.

No, in a single folder

do you have season folders?

Hi @Luke - I can't speak for some of the other issues mentioned as I never really experienced those (such as skipping a few seconds without reason), however, the specific issue I was running into when pausing a video the audio continues to play for a few seconds and resuming the audio delays for a few seconds actually seems handled for me. Stopping, pausing and restarting sees no delay in the audio. However, a new thing that happens is I am noticing an occasional audio drop out (very brief, like less than a second). It seems random when it happens. Sometimes it occurs a few seconds after restarting from a paused video, sometimes it happens after the video has been playing for a little while.