Additional Options for metadata folder and storing images etc. next to media

[Clackdor 129]

Basically the idea is to expand on the current options to either use the metadata folder only (default behavior), store images, BIF files, NFO files, etc. next to media and optionally whether or not to copy that back to the metadata folder (essentially using the metadata folder as a read cache). The current options/behaviors could be put into a drop down menu along with the aditional options.

The first additional option would be an inverse of the current option to make a copy of images to the metadata folder. Basically the metadata folder will be the primary location to write and read images etc. from, but any changes will still be copied over to the media folders. This makes the metadata folder the "source of truth" and prevents any unwanted alterations/deletions/corruption of images occuring externally as emby could just replace them from the metadata folder. On the initial library creation or new library addition do a one-time copy of images/etc. from the media folder to the metadata folder. Afterwards any further changes will then go from the metadata folder to the library folder and any external alterations will be overwritten by emby unless the item is deleted/renamed, etc. 

The second option I propose would basically use the metadata folder as a write cache, but still use the media folders as the primary location to read from. Like the first option, the metadata folder becomes the "source of truth"  for any changes, but reads should still happen from the library folders. I'll admit this one may be a bit more niche than the first option, but I still see some utility to this assuming it wouldn't cause too much additional complexity or conflicts. 

These options would expand on the existing ones to allow better fine tuning of performance, data flow, and consistency for different storage setups whether it be separate NAS & Emby server, or a single machine with a mix  storage that is pooled, tiered, or split into separate arrays, volumes, etc. I personally use Stablebit Drivepool on my server and have a mix of HDD's and SSD's and NVME drives in various pools and subpools.

I think they would also be useful for others like myself that are running multiple Emby instances pointed to the same library folders for separation, testing, or a variety of other reasons.

[Luke 43439]

Quote

The first additional option would be an inverse of the current option to make a copy of images to the metadata folder.

HI, we have this already with the caching option on each library.

[Clackdor 129]

24 minutes ago, Luke said:

HI, we have this already with the caching option on each library.

 

39 minutes ago, Clackdor said:

The first additional option would be an inverse of the current option to make a copy of images to the metadata folder

The current behavior writes to the media folder first, then caches a copy to the metadata folder, basically just using the metadata folder as a read cache. As an example, with the existing option if I make change to a poster next to the media the version in the metadata folder gets updated with that image. 

The first option I suggested reads/writes from/to the metadata folder as the primary location, but also writes a copy to the media folder. In this situation the metadata folder would be acting as a write cache as well as read cache.  As an example, if the poster stored next to the media gets changed, that change is not seen by emby and will later be overwritten by a libary scan/scheduled task, etc with the poster from the metadata folder. This prevents any unwanted changes being permanently made to images stored next to media by another emby instance, other software monitoring media folders, accidental deletion, etc. 

 

[Luke 43439]

Quote

The first option I suggested reads/writes from/to the metadata folder as the primary location, but also writes a copy to the media folder. In this situation the metadata folder would be acting as a write cache as well as read cache.

I don't think there's really a difference though.

Quote

As an example, if the poster stored next to the media gets changed, that change is not seen by emby

Yes it will because the server captures the date modified timestamp of the file.

[mrmixed 81]

Continuing this thread, I'd like to see an option to allow NFO files (as well as BIF and images, etc.) to be saved in a location other than the media folders.  For my own compulsive reasons (mostly to promote ease of finding files using alternative media players), I want the media folders to stay clean without a lot of superfluous files.  So I prefer to only store video files within the media folders, and am willing to concede subtitle files as well, since they have utility as most other media players can pick them up. 

I really want to save NFO files because I've had very bad experiences where metadata refreshes within Emby have undone hours of configuration (I discovered too late that it's not enough to simply identify a title that Emby misidentified; if you don't lock in the metadata after manual identification, a refresh will destroy it).  But I'd like to be able to allow the NFO files to live in a parallel location managed by Emby, and not in my media folders.  It makes sense to do the same thing for images as well (this would also help prevent similar disasters when my custom image selections got blown out upon refresh when Emby again re-misidentified a title that wasn't locked).  And doing the same for BIF files just seems like a natural progression to keep the original media folders clean.

Ultimately, I have learned to not to ever refresh metadata, but my prior experiences, along with several comments relating to NFO files in this forum, really reinforce the idea that not having an NFO backup is a recipe for eventual doom.  I'd just like to be able to do it neatly, without dumping the NFO files into the media folders, and to place them instead in a parallel structure, whether it's metadata, cache, or something new.

[katbyte 51]

+1 I would also like some more control over what files can be "cached" locally where emby is running.

specifically this option didn't behave like i expected it to:

as it also keeps a local copy of the preview thumbnails, the -320-10.bif files locally - this caused my emby folder to ballon to over 900gb and the vm disk is now 1tb.

this matters to me because i DO want to cache artwork (100gb) as it is faster to browse, but i don't want to cache the bifs (~750gb) as it doesn't affect much being on the NAS.

i turned that off for some libraries to see what would happen and after regenerating images those libraries obviously slower to interact with.

[Luke 43439]

57 minutes ago, katbyte said:

+1 I would also like some more control over what files can be "cached" locally where emby is running.

specifically this option didn't behave like i expected it to:

as it also keeps a local copy of the preview thumbnails, the -320-10.bif files locally - this caused my emby folder to ballon to over 900gb and the vm disk is now 1tb.

this matters to me because i DO want to cache artwork (100gb) as it is faster to browse, but i don't want to cache the bifs (~750gb) as it doesn't affect much being on the NAS.

i turned that off for some libraries to see what would happen and after regenerating images those libraries obviously slower to interact with.

More options are possible, but the reason for this is that the detail screen uses those thumbnails. If they're not included in the cache, then clicking into a video detail screen could cause a drive spin up.

[katbyte 51]

i'm not worried about a drive spinning up (they never stop in my server) I would like to balance performance (what lives on smaller fast expensive SSDs locally) and space (what is on the slower larger NAS HDDs)

testing now the detail screen is maybe? slightly faster to load for the libraries where images and thumbs sit locally but its nearly impossible to tell. the nature of click/load new screen hides it well.

while for the artwork/posters scrolling down through a library it is very obvious which library has them locally and which does not.

So maybe the option i'm really looking for is "cache posters for library browsing locally with no expiration" ?

[katbyte 51]

@Lukealternatively to creating a new config option, just moving the server location the bif files are stored would be good enough as i could make the same change i just did to gets jellyfin's scrub files off the server onto the NAS:

    volumes:
      - /home/docker/config/embyfin/jellyfin:/config
      - /home/docker/volumes/jellyfin/cache:/cache
      - /mnt/data/video/.trickplay:/config/data/trickplay

as emby puts the bif files into `metadata/library` with everything else i cannot do the same trick.

[Luke 43439]

I would prefer the first approach over the second one.

[katbyte 51]

Either would work for me!

also i hit a bug/gap regarding scrub images - I deleted them all thinking it would be easy to have the server regenerate them and that doesn't appear to be the case. While this option "works"

it always goes over the entire library and for a large one that would take days (1000s of shows)  you can not add or scan anything else, less then ideal. The scheduled task doesn't seem to pick up that they are missing. And there didn't seem to be any other way to trigger a recreation of them for only the ones that are missing?

Edited October 8 by katbyte

[Luke 43439]

If you delete files manually, the scheduled task will figure that out.

[katbyte 51]

It appears that one has to fully reboot the server first (or crash it in my case here) for it to start working as i tried it multiple times in a row and it would run for a couple seconds with clearly broken chapter/scub images, or adding them to new media - and not restart in settings, that didn't do it.

scheduled task is now doing its thing after a fresh start, thanks! 

[Luke 43439]

You shouldn't have to restart the server.

[katbyte 51]

Seems i was wrong, the Video preview thumbnail extraction task is not creating BIF files for the missing BIF files anymore:

just ran the task and it finished quickly

 2026-10-20 12:28:16.696 Info ScheduledTaskService-0HNPEH25895SA:00000006: http/1.1 POST http://x.x.x.x/emby/ScheduledTasks/Running/d15b3f9fc313609ffe7e49bd1c74f753?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome macOS&X-Emby-Device-Id=953bf26b-a8f4-4c32-a632-e4199f74443c&X-Emby-Client-Version=4.11.0.8&X-Emby-Token=<hidden>&X-Emby-Language=en-gb. Source Ip: x.x.x.x, UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/155.0.0.0 Safari/537.36
  2026-10-20 12:28:16.698 Info TaskManager: Executing Video preview thumbnail extraction
  2026-10-20 12:28:16.698 Info ScheduledTaskService-0HNPEH25895SA:00000006: http/1.1 Response 204 to x.x.x.x. Time: 2ms. POST http://m.x.net/emby/ScheduledTasks/Running/d15b3f9fc313609ffe7e49bd1c74f753?...
  2026-10-20 12:28:18.689 Info TaskManager: Video preview thumbnail extraction Completed after 0 minute(s) and 1 seconds
  2026-10-20 12:28:27.919 Info ScheduledTaskService-0HNPEH25895S9:0000000A: http/1.1 POST http://x.net/emby/ScheduledTasks/Running/d15b3f9fc313609ffe7e49bd1c74f753?...
  2026-10-20 12:28:27.919 Info ScheduledTaskService-0HNPEH25895S9:0000000A: http/1.1 Response 204 to x.x.x.x. Time: 1ms. POST http://x.net/emby/ScheduledTasks/Running/d15b3f9fc313609ffe7e49bd1c74f753?...
  2026-10-20 12:28:27.919 Info TaskManager: Executing Video preview thumbnail extraction
  2026-10-20 12:28:29.818 Info TaskManager: Video preview thumbnail extraction Completed after 0 minute(s) and 1 seconds

and you can see there are missing BIF files

2026-10-20 11:54:39.879 Info ImageService-0HNPEH25895K8:0000000A: http/1.1 Response 404 to x.x.x.x. Time: 10ms. GET http://x.x.x.x/emby/Items/2036162/Images/Chapter/0?maxWidth=724&tag=59a2fa024a443a87bbc280c4705259dd_0&mediaSourceId=mediasource_2036163&quality=90.
2026-10-20 11:54:39.879 Info ImageService-0HNPEH25895K6:00000002: http/1.1 Response 404 to x.x.x.x. Time: 9ms. GET http://x.x.x.x/emby/Items/2036162/Images/Chapter/2?maxWidth=724&tag=59a2fa024a443a87bbc280c4705259dd_0&mediaSourceId=mediasource_2036163&quality=90.
2026-10-20 11:54:39.879 Error ImageService-0HNPEH25895K8:0000000A: Error processing request
        *** Error Report ***
        Version: 4.11.0.8
        Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
        Operating system: Linux version 6.12.111+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debia
        OS/Process: x64/x64
        Framework: .NET 8.0.28
        Runtime: system/System.Private.CoreLib.dll
        Processor count: 16
        Data path: /config
        Application path: /system
        MediaBrowser.Common.Extensions.ResourceNotFoundException: MediaBrowser.Common.Extensions.ResourceNotFoundException: Thumbnail set not found.
           at Emby.Api.Images.ImageService.GetThumbnailImageResult(ImageRequest request, Int64 positionTicks, Int64 itemId, Boolean isHeadRequest, Nullable`1 cacheDuration, Boolean validateTag, CancellationToken cancellationToken)
           at Emby.Api.Images.ImageService.GetImage(ImageRequest request, Int64 itemId, BaseItem item, Boolean isHeadRequest)
           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, RestPath restPath, String urlString, String localPath, String contentTypeInPath, CancellationToken cancellationToken)
        Source: Emby.Api
        TargetSite: Void MoveNext()

and basically everything has broken ones like

embyserver.txt

[katbyte 51]

don't worry about digging into it, rather then try and figure out what wasn't working/wait for a fix i just asked AI to write something quick that would just create them https://github.com/katbyte/emby-bif-builder 

scans the library and figures out what files are missing BIFs, or have corrupted BIFS (1 image or to many there were many) and then can just create them from the file or copy them from JF trickplay folder as it happily has been chugging along creating them for weeks now - bonus it's 640x images work just fine and look noticeably sharper on all my devices

 

[ginjaninja 663]

On 06/10/2026 at 07:12, Luke said:

then clicking into a video detail screen could cause a drive spin up.

I agree "(spinning rust) drives not spinning up until media is played (or metadata changed)" is a worthwhile goal. Ensuring everything is cached to ensure fluid ui navigation (and minimise energy usage) is desirable (inc. for users who store metadata in media folders (to protect their chosen metadata)).

[Luke 43439]

1 minute ago, ginjaninja said:

I agree "(spinning rust) drives not spinning up until media is played (or metadata changed)" is a worthwhile goal. Ensuring everything is cached to ensure fluid ui navigation (and minimise energy usage) is desirable (inc. for users who store metadata in media folders (to protect their chosen metadata)).

To that end, the only thing it currently does not copy is theme songs and theme videos, because those could get really large.

[Luke 43439]

13 hours ago, katbyte said:

don't worry about digging into it, rather then try and figure out what wasn't working/wait for a fix i just asked AI to write something quick that would just create them https://github.com/katbyte/emby-bif-builder 

scans the library and figures out what files are missing BIFs, or have corrupted BIFS (1 image or to many there were many) and then can just create them from the file or copy them from JF trickplay folder as it happily has been chugging along creating them for weeks now - bonus it's 640x images work just fine and look noticeably sharper on all my devices

 

Just be aware that if you use Roku, it may actually cause playback failures if the images are not the size that Roku is expecting.

[katbyte 51]

i do not use Roku but thanks for the heads up, i tested it with all the devices/apps i do use and twas fine.