All Activity

Try obtaining external srt subs and place them in the same folder as strm file (name them identical as strm)? You can also extract those ASS subs to srt with the tool of your preference (like SE), it literally few-seconds process.

If you are using VPN or other proxy, these could be causing some stuttering.

Yes. We all have full access to all Libraries.

I owe you all an update: my problem had nothing to do with Emby or my network. You can read all about my adventure over here: https://forums.servethehome.com/index.php?threads/lsi-9400-16i-power-on-or-device-reset-occurred.55002/ but in summary, the backplane in my server chassis (Gooxi RMC4136-670-HSE chassis) had an old firmware that had issues with some health checking commands while drives were loaded (reading or writing). If I was streaming something from it and a TrueNAS health check occurred (which turns out is every 90 minutes in 25.10) then it would cause the drives to start timing out leading to ZFS halting the pool while it recovers the drives and while that is happening all further reading is blocked which from Emby's perspective looked like a network timeout. It would take about 5 minutes for all the drives to recover and then it would be fine until the next health check. Gooxi was able to provide a newer firmware and it has completely resolved the issue.

v1.7 Logic refined Color accents refined emby_album_tag_importer.py

Yeah just done that there just now, I uninstalled then re-installed again. I am at the library stage again and when I click on storage nothing happens.

If I play the file through the same Emby web app directly without using the strm file, it works fine. So I'm not sure it should have anything to do with the media itself? It should just play it the same as if playing it directly, no? I did just try another browser (Chrome) and that did not work. Playing it without subs actually does work, but that doesn't do me much good since I need to be able to play it with subs. Hmm. So it seems to be a combination of both routing through the stream file and having subs enabled.

Of interest - Recent post regarding video stuttering with Apple TV - Apparently, this is a known issue for many years with Apple TV. Often updates happen behind the scenes and users are unaware that anything changed. https://thetechgorilla.com/apple-tv-stuttering/

Interesting. This makes sense. I will find the folders that are using a screen cap and drop in generic posters to force their showing...which should then make them all portrait mode methings. Stay tuned... Kev.

Basically correct but I think we just look at the first few items. When dealing with mixed content where we cannot predict the image shape, we try to do a best guess based on the result set.

That is fine I just checked it and it appears the problem came back. I will refer it to gracenote

It's just using whatever the majority of items are when it loads the first page. Changing the sort order changes what percentage of items on the first page are one orientation vs the other.

This is an expected side effect of CSS styles that are set for the entire image results of any list, to never stretch images so that when there are mixed portrait and landscape images, no image is cropped or stretched. When you sort differently, the stray landscape or portrait image does not show up, so the results images match all of one type. I think emby goes to the the first background image, which is usually landscape format if there is no poster. The CSS styles can be carefully set for to test each image and adjust individually, but that is quite tricky. Typically, it is easier to set image styles for an entire list. Often professional online sites just have the admin always control images for poster art to be portrait. Then this issue goes away. I think since, the code using the first background image, when there is no poster is what is causing this mixup.

Unrelated...ffprobe is throwing segfaults. I am running 4.10.0.9 switching to 4.10.0.10. I could flip back to stable and see if the view issue or ffprobe clean themselves up. FYI running in docker. 2026-04-14 08:02:28.728 Info MediaProbeManager: ProcessRun 'ffprobe' Execute: /bin/ffprobe -i file:"/Concerts (Bootleg)/David Gilmour - (2024.10.31) Hollywood Bowl, Hollywood, CA (A1, Scorps151)/David Gilmour - (2024.10.31) Hollywood Bowl, Hollywood, CA (A1, Scorps151).mp4" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format -show_data 2026-04-14 08:02:28.818 Info MediaProbeManager: ProcessRun 'ffprobe' Process exited with code 139 - Failed 2026-04-14 08:02:28.818 Error App: Error in ffprobe

Hi. Please change your username on this forum to not be your email address. Thanks.

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

Update: If I change the sort order, then it reverts to normal. Note that if I sort by something innocent like video codec, it give me flips. This is not consistent across all sorts. Doing this by framerate is ok both ways!

Any well maintained skin, but I recommend not using (skin) helpers at all. They are a source of trouble and there is absolutely no need for any helpers.

Hi Luke. With no intervention from myself, other than perhaps some unknown schuleded Emby activity overnight, it reverted to normal again. I will add that it flipped to the other way (Pic 2) after I ran a small python script I made accessing the API that reads the filename of the item and pushes it into Emby to change the Title, Original Title, Sort, and Year fields (so I don't have to manually enter them...) and then locks each field, plus flips the toggle "Lock this item to prevent"... I will let it sit for another day and see if it reverts...odd! Kev. Pic 1: Pic 2:

Hi, I find the media search quite slow (around 5 seconds required on most case). I think it is normal and simply due to the size of my library. Anyway, I'm looking for ways to speed things up, if possible. For context: - Emby version: 4.9.3.0 running bare-metal on Debian 13 - Hardware: Emby is installed on a rather low-end SSD (but still an SSD), Intel core 12100 CPU (4 cores / 8threads) 128Gbytes or ram (should not be the bottleneck). My point being the SQlite files are on SSD. - Media library: on a big pool of hard drives running ZFS in raidz3 mode (5+3) Since what is a bit slow at my taste is the media search, I'm looking at ways to optimize SQLite (in particular reads). I don't have many concurrent users. I changed the database cache parameter to 4096Mbytes and restarted the Emby server (systemctl restart) and I did the "clean DB at startup". Search still feels slow, though browsing through the site might seem faster. So my question now is (I'm unfortunately not a DB expert): - Is it safe to change SQLite parameters (sqlite3 library.db) manually outside the Emby software? I guess yes. - I noticed WAL is enabled and that 'synchronous' is set to FULL . According to what I understand from SQLite3 doc (https://sqlite.org/pragma.html#pragma_synchronous) it seems to be safe enough to set synchronous to NORMAL when WAL mode is enabled. Would you advise against it? - PRAGMA cache_size yields -2000 (which means 2000kbytes of cache) and not 4096Mbytes like I have set in the WEB GUI, but I guess it is because Emby relies on the "Application Defined Page Cache". Or is there an issue with the size of the cache? - mmap_size is set to 0, apparently this settings is the number of bytes that can be accessed using memory-mapped I/O and apparently it allows to use an OS cache for SQLite file. Should I allocate a few Gbytes to it? - temp_store is set to 0 by default (file), apparently setting up to 2 could make SQLite store some indexes and temporary tables in RAM - Other ideas for search optimization? Thanks.

Hi! I'm so sorry if I'm posting this in the wrong place as I haven't used a forum in a long time and while I did search I couldn't find anything that matches exactly. The issue I'm having is that while I was able to watch anime I have with OPUS audio just the other day, it seems there's been an update and now it's not working. I've so far found the best experience to be playing it via the XBOX app (I would prefer to use my LG TV + Emby app but I know they have OPUS issues and it wasn't worth the headache) but I've also tried tonight to play it via browser on my Mac (Firefox browser) and it just freezes and doesn't work. When I've had this issue before I've used the Playback Correction Button in the settings but it seems to now be missing, so unless I want to change the quality from Auto to say 720 to force it to transcode (I have the Premium Version), it won't play at all and just sits there frozen. This is not ideal as I'm generally trying to watch things at 1080 etc. Is there a way to force everything to just transcode automatically to avoid this issue? Even if the Playback Correction button is reinstalled it won't be ideal for Re:Zero for example as it plays little 2 minute skits between each episode so waiting for it to freeze on a failed direct play then forcing the transcode is really tedious. Note I'm running a docker setup on a Synology NAS. Thanks for any help and advice! Snow

As a new user Members Group applies.

If have both options listed, use QS instead of VAAPI.Glad you fixed it.

I finally got it working. I didn't have any VAAPI options for preferred hardware encoders, just the quick sync, once I disabled those, I guess it fell back to the GPU (preferred hardware decodes are set to VAAPI DG2 Arc A380.

This need can be solved by attaching the font files into .ass files itself. You can do it using Subtitle Edit. If you need a batch processing, you can try assfont tool. Assfont with GUI: https://github.com/wyzdwdz/assfonts/ So ,we do not need to change the fonts on server side or client side. Note: Do not forget to use Emby App, not Android TV version. Tested on theese platform/devices: Android TV Google TV tvOS iOS Android Mobile Web Client Emby Client for Windows All these devices/os are problem-free with font attached ass subtitles. I've bought Emby Premiere for Lifetime just for this implementation. Btw, @Lukewe're willing to see this feature on Emby for Android TV version.