Using existing images for new libraries

[CRiXiD 25]

I'm wanting to migrate my libraries from my docker install on a NUC to a Silicone Mac, and with the inability to access GPU on Mac within docker I'm trying to use the native app, meaning that my resource paths are no longer the same. When adding a library with "Save artwork into media folders" checked, I'm surprised to see that the artwork stored in media folders is being ignored or overridden on import. I've reviewed the naming convention docs, and using posters as an example, all images are either poster.jpg or {name}-poster.ext (as you'd expect, given that Emby created them to begin with). When the new item is added to the library,

• Any instance of poster.jpg is ignored, with a new {name}-poster.ext created
• Any instance of {name}-poster.ext is just overridden

How do I get Emby to use the local artwork? I've spent A LOT of time setting up artwork I like.

[GrimReaper 4739]

Well, that shouldn't be happening as, by default, local artwork should have priority; nevertheless, you can disable all internal artwork fetchers when setting up library, so no new images can/will be downloaded and existing images overwritten. Do tell us how it went.

[CRiXiD 25]

I'll try that, thanks

[CRiXiD 25]

Unfortunately if I disable the image fetch sources the library item is just added without a poster. I have also checked that the existing artwork permissions are ok, and they are identical to the newly created artwork that Emby adds if fetching is enabled, which in theory is also confirmed by the fact that Emby also happily overrides any existing instance of {name}-poster.ext.

Edited August 18, 2025 by CRiXiD

[GrimReaper 4739]

6 minutes ago, CRiXiD said:

Unfortunately if I disable the image fetch sources the library item is just added without a poster.

That would indicate that local artwork is not read/not linked with media item (as if not present) for some reason - could you share a screenshot of one of the media folders? 

[CRiXiD 25]

Sure thing. What do you want the screenshot of, the folder in Mac OS?

[GrimReaper 4739]

Yep. 

[CRiXiD 25]

This is the folder I tested with fetchers disabled. All existing artwork was created by Emby on linux / docker.

[CRiXiD 25]

Here are the permissions for reference 

[GrimReaper 4739]

Nothing sticks out there, that should definitely work. Is poster-type image the only one that doesn't get read or no artwork type gets imported? As a test, if you rename poster.jpg to folder.jpg, does same occur? 

[CRiXiD 25]

No artwork gets imported. After renaming poster.jpg to folder.jpg 

and re-adding that folder as a source, this is the outcome

[Luke 42077]

HI, what are the complete contents of the folder?

[CRiXiD 25]

As above, nothing else in there 

[CRiXiD 25]

For reference, I am on 4.8.11.0

[GrimReaper 4739]

Another test: if you remove NFO file prior importing, does artwork get read?

Edit: To clarify, in case you're saving image paths within NFO files and due to resource paths change, maybe it's breaking parser i.e. when reading NFO Emby ain't finding artwork at written paths. Just trying to think of what might be the reason, as my whole library is driven by externally-obtained artwork.

Edited August 18, 2025 by GrimReaper
Append

[CRiXiD 25]

This time the behaviour was a bit different. Despite image fetchers being disabled, it just went ahead and fetched artwork anyway. It still ignored all existing artwork though.

Edit - For reference, the nfo in the above screenshot was created during the import. I had deleted it prior as per your directions.

Edited August 18, 2025 by CRiXiD

[CRiXiD 25]

I just checked some other nfo's from other folders exhibiting the same behaviour (they all behave the same way), and they don't have references to artwork, nor file paths.

Edited August 18, 2025 by CRiXiD

[GrimReaper 4739]

3 minutes ago, CRiXiD said:

Despite image fetchers being disabled, it just went ahead and fetched artwork anyway.

That should definitely not be happening. You positive that all image fetchers are disabled and you don't have that movie in any other library?

As that naming scheme should apply only to multi-movie folders or multi-version movies, not a single movie in it's own folder.

 

 

[Luke 42077]

Well we can't see all of the folder contents, but I think this is improved in the upcoming 4.9 release. Thanks.

[CRiXiD 25]

2 minutes ago, GrimReaper said:

That should definitely not be happening. You positive that all image fetchers are disabled and you don't have that movie in any other library?

As that naming scheme should apply only to multi-movie folders or multi-version movies, not a single movie in it's own folder.

 

 

I don't have any other libraries, however I'll just delete this library outright (it only has the one folder to test) and re-add with the fetchers disabled.

[CRiXiD 25]

10 minutes ago, Luke said:

Well we can't see all of the folder contents, but I think this is improved in the upcoming 4.9 release. Thanks.

Ah ok, what's changing in 4.9 broadly re this issue? And rough ETA? I can update to beta if it's already available to test.

Edited August 18, 2025 by CRiXiD

[CRiXiD 25]

7 minutes ago, GrimReaper said:

That should definitely not be happening. You positive that all image fetchers are disabled and you don't have that movie in any other library?

As that naming scheme should apply only to multi-movie folders or multi-version movies, not a single movie in it's own folder.

 

 

Ok, after deleting the library and creating it with the fetchers disabled, it didn't pull down new artwork if nfo was absent. That must have been a caching issue or something, as I had toggled artwork fetching on and off again after a prior attempt. In any case, the existing artwork is still not being read.

[GrimReaper 4739]

That's good, but it still doesn't explain why fetched artwork was pulled and named in such convention, as if it was movie in a multi-movie folder or it were a multi-version movie.

Another test: if you rename media file so it doesn't follow multi-version naming convention ("space-dash-space" after folder name), i.e. just "LOTR (2022).mkv" while dumping cut and mediainfo suffixes for example, how does it behave?

Edited August 18, 2025 by GrimReaper

[CRiXiD 25]

14 minutes ago, GrimReaper said:

That's good, but it still doesn't explain why fetched artwork was pulled and named in such convention, as if it was movie in a multi-movie folder or it were a multi-version movie.

Another test: if you rename media file so it doesn't follow multi-version naming convention ("space-dash-space" after folder name), i.e. just "LOTR (2022).mkv" while dumping cut and mediainfo suffixes for example, how does it behave?

Same outcome unfortunately - no reading of local artwork

[CRiXiD 25]

Ok, some progress - It is reading the local artwork now, if I rename poster.jpg to The Lord of the Rings The Two Towers (2002)-poster.jpg. I'll test that again using the older multi version naming format.