All Activity

Ah you're right, runtimes within 5 minutes were treated as the same version, so the second credits submission was seen as overlapping the first. I've tightened the version grouping to 2 minutes (from 5), which still absorbs encode-level length differences but lets close-length re-cuts like T2's be submitted separately. Feel free to try submitting now!

I upgraded my local version of Electron to version v40.0.0, Chromium v144.0.7559.60, Node v24.11.1, v8 v14.4.258.16, and this what the Folder images look like now. Is this the intended designed look? Emby Theater 3.0.20 is currently using Electron v11.5.0 which was released back in August 30, 2021. Electron release notes: End of Support for 11.x.y Electron 11.x.y has reached end-of-support as per the project's support policy Developers and applications are encouraged to upgrade to a newer version of Electron.

Good question, the plugin doesn't use chapters to decide what to fetch. Every movie/episode is looked up by its TMDb/TVDb/IMDb ID, so both kinds of files are checked against the DB. What you're seeing is Emby itself: for files with no embedded chapters, Emby generates placeholder chapters (~every 5 minutes) during scans, and that write replaces the whole chapter list — including the markers the plugin added. Files that do have embedded chapters never get regenerated, so the markers stay. Re-running the TheIntroDB Media Segment Scan after a library scan normally restores them, but if Emby regenerates those chapters afterwards they can get wiped again. There's no Emby API for a plugin to say "my chapters must win," so it's a platform limitation I'm still working around. If you want to confirm, the plugin log will show either "TheIntroDB saved N chapters/markers" or "API returned no data" for a given file.is In the trouble shooting section on the plugin's GitHub page it does state: It's recommended to disable Emby's internal intro marker detection in Dashboard → Library → select library → Advanced/options → Disable "Generate intro video markers".

So I am still on CachyOS, but I ended up converting all my drives to BTRFS (except 1 SSD I use to dual boot Windows but that shouldn't matter here). Normally I can watch any media on any drive and everything plays fine. I have other TV Series on this same drive as Tulsa King S02. Heres the output from ls -al: drwxrwsr-x - xplorer4x4 16 May 2025  'Tulsa King S02' The permissions are the same on every other folder for every other TV series or TV season on the drive. They all get marked in the database as watched, and they "play all" just fine. Could this just be a bad encode? Also, the only odd thing I spot in the server log is this: I don't get the http/1.1? And here is my fstab line for that drive: UUID=53cb5f0b-4994-4723-b0eb-a3b4c8fc4be9 /mnt/WD3 btrfs noatime,nofail,users,rw,x-gvfs-show,compress=zstd:6 0 0 Any details I am missing?

I also returned to 4.8.11.0. 4.8 Using the Bluray Folder Support plugin version 1.0.2.0 is normal, while versions 1.0.3.0 and above used in 4.9 cannot recognize the BDMV folder structure. Although it has been updated to 1.0.5.0, the issue still persists. We hope to find the problem and update the plugin.

Hi, what exactly was clicked on?

It’s not by design. It’s just that freaking with the older chromium’s version is a work in progress.

Hi, the smb library we’re embedding is probably opening a new connection per file access, however they shouldn’t be left open.

emby_macos_1786322107083.189.txt I've been having this issue where media I'm playing in the Emby app (2.2.56) would randomly seek to the next episode without my asking. Today I was working on a task that had a bit of secondary clicking involved and every time I did a secondary click, it went to the next episode. This also held true if I did a Control-Click. It seems to only occur while the app is in full screen mode. It doesn't seem to matter if it's in focus or out of focus. Initially I thought it was a macOS problem, but this doesn't occur with Spotify. For the sake of testing I grabbed the download of an older Emby app (2.2.39) for macOS and the problem doesn't seem to occur. Log files are attached.

I just keep telling myself that $4 a month doesn't mean a request that is over a decade old will ever be granted.

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.