All Activity

OK we'll take a look at it. Thanks.

353 Bonjour, j'ai Emby première. Pour les amoureux des BD j'ai essayé KOMGA qui est juste parfait pour récupérer les métadatas de nos albums. Je l'avais installé sur mon NAS via docker mais j'ai eu l'impression que la méthode n'était pas fiable. Existe t'il une extension pour EMBY qui fait la même chose car pour le moment c'est très pauvre ? Merci à tous. Hi, I have Emby Premiere. For comic book enthusiasts, I tried Komga, which is absolutely perfect for fetching album metadata. I had it installed on my NAS via Docker, but the method didn't seem reliable. Is there an Emby plugin that does the same thing? The current support is very limited. Thanks, everyone.

Anything, browser windows, text documents, this dialog box, if I secondary click, it skips to the next episode.

That's the current intended look yes.

8月8日晚上9点45分之前（具体时间记不清了），在地下二层四楼的主卧室里，《破船记》这部剧从第9集开始自动播放，一直播放到第10集，然后屏幕变黑，应用程序崩溃，返回到Emby主界面。我为这部剧使用了外部的.ASS字幕文件，我想知道这是否与字幕文件有关。 hardware_detection-63921822988.txt hardware_detection-63921822761.txt embyserver.txt

So, ich habe jetzt die Beta 4.10.0.23 auf meinem Synology Installiert, die Funktion mit der Zufallsanzeige ist Wunderbar! Dafür gibt es 10 Punkte Auch die Funktion zur Ansicht der letzten hinzugefügten Folge einer Serie in der Übersicht ist euch gut gelungen. So sieht jetzt meine Startseite aus: Die Zufallsanzeigen habe ich in "Roulette" umbenannt. Was ich leider vermisse: Die Einstellungen für einen definierten Intervall ( 24 / 48h oder 1 - 5 Tage) Was ich leider immer noch Vermisse: Die IMDb Anzeige auf der Startseite unter Filmen und Serien! Wenn ihr das auch noch hinbekommt, seid ihr für mich die Größten

I included the portion of the server log at the time of the crash in my OP. I'm happy to share the full log but is there a private way for me to provide it? Thanks Luke.

EmbyVision Credits 1.0.0.1 — Stable Release - EncryptedCity I'm releasing EmbyVision Credits 1.0.0.1, the first stable release of my automated credits detection plugin for Emby. EmbyVision was built from the ground up for accurate credits detection, large media libraries, performance, and modern video formats including AV1. What It Is EmbyVision Credits is the detection engine that runs inside Emby and handles the credits detection workflow. For OCR processing, EmbyVision uses PaddleOCR through a separate self-hosted OCR service. This keeps the OCR workload separate from the Emby plugin and allows users to choose between CPU and NVIDIA GPU processing. Important — Installation Notice Do not install EmbyVision Credits alongside the original Emby Credits plugin. EmbyVision Credits is a separate replacement project with its own detection engine and processing architecture. Running both plugins at the same time can cause conflicts and prevent EmbyVision from operating correctly. If you are migrating from Emby Credits, remove or disable the original Emby Credits plugin before installing EmbyVision Credits 1.0.0.1. OCR Editions CPU Edition For systems without an NVIDIA GPU. OCR Engine: PaddleOCR Processing: CPU Port: 8000 Docker: ghcr.io/encryptedcity/embyvision-ocr:latest GitHub: https://github.com/encryptedcity/embyvision-ocr NVIDIA GPU Edition For systems with a compatible NVIDIA GPU. OCR Engine: PaddleOCR Acceleration: NVIDIA CUDA + cuDNN Port: 8001 Docker: ghcr.io/encryptedcity/embyvision-ocr-gpu:latest GitHub: https://github.com/encryptedcity/embyvision-ocr-gpu The GPU edition is intended for larger libraries and systems where OCR processing would otherwise place a significant workload on the CPU. Release Information Plugin: EmbyVision Credits Version: 1.0.0.1 Status: Stable Detection Engine: EmbyVision Credits OCR Engine: PaddleOCR CPU OCR: Port 8000 NVIDIA GPU OCR: Port 8001 Deployment: Self-hosted / Docker Developer: EncryptedCity Links EmbyVision Credits https://github.com/encryptedcity/EmbyVision-Credits EmbyVision OCR — CPU Edition https://github.com/encryptedcity/embyvision-ocr EmbyVision OCR — NVIDIA GPU Edition https://github.com/encryptedcity/embyvision-ocr-gpu Installation instructions, Docker configurations, releases, and source code are available in the respective repositories. This is the 1.0.0.1 stable release of EmbyVision Credits.

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.