Emby doesn't read my local image files but download from internet.

[Yihang 0]

There are files in the movie folder such as "poster.jpg", "fanart.jpg", "logo.png" and else. But Emby keeps downloading "***(movie name)-poster.jpg", "***-fanart.jpg", ...

After I deleted these new files, the movie poster on the client became blank. Then the server starts downloading again.

How can I avoid this from happening? Thank you.

Not every movie has this issue. Mostly the local image file works.

[Abobader 3470]

Hello Yihang,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[GrimReaper 4749]

How does your folder structure look like? Are those multi-movie folders? 

[Yihang 0]

Thanks for your comment, it's really helpful. 

I realized that there is a sample video in the subfolder of this movie folder. I deleted it then the image files work!

During this time I found another problem. I tried renaming the poster and fanart images to keep the same with the files Emby downloaded. For example, rename "poster.jpg" to "Spiderman-poster.jpg". I thought it can help to keep the poster I choose. But the server still downloaded new files and overwrote the files.

This may not be a bug, but a little confusing. 

[GrimReaper 4749]

Not knowing your folder structure, but if each movie in its own folder, then poster.jpg, fanart.jpg, logo.jpg etc. would do just fine, no need to prefix those with <moviefilename>. 

Quote

Video images

Images are supported in video folders. Below is a table of the supported image file names. Supported image extensions are jpg, jpeg, png, gif and tbn.

Several image types support multiple file names. They are listed in the order that they're checked for.

Image Type	Supported file names
Primary	{name}.ext
	{name}-poster.ext
	{name}-cover.ext
	{name}-default.ext
	{name}-movie.ext
	folder.ext
	poster.ext
	cover.ext
	default.ext
	movie.ext
Art	{name}-clearart.ext
	clearart.ext
Backdrop	backdrop.ext, backdropX.ext
	fanart.ext, fanart-X.ext
	background.ext, background-X.ext
	art.ext, art-X.ext
	extrafanart (subfolder)/fanartX.ext
Banner	{name}-banner.ext
	banner.ext
Disc	{name}-disc.ext
	{name}-cdart.ext
	disc.ext
	cdart.ext
Logo	{name}-logo.ext
	logo.ext
Thumb	{name}-thumb.ext
	{name}-landscape.ext
	thumb.ext
	landscape.ext

{name} represents the video file name, without extension. For videos that are not contained within their own folder, only the conventions using {name} are supported.

 

For backdrops, X represents a number, and you can have any amount of numbered backdrops. For example:

 \Movies
    \300 (2006)
       backdrop.ext
       backdrop1.ext
       backdrop2.ext
       backdrop3.ext 

https://support.emby.media/support/solutions/articles/44001159102-movie-naming

 

[Luke 42083]

Hi there, how are your files named and organized?

[MrAudio 22]

This is an example of the bug that I reported several months ago. Emby had long supported multi-part movies - example:

 

\Star Wars (1977)\Star Wars (1977) - Part 1.mp4

\Star Wars (1977)\Star Wars (1977) - Part 2.mp4

\Star Wars (1977)\Star Wars (1977) - Part 3.mp4

\Star Wars (1977)\folder.jpg

 

But a new build of Emby about 3-4 months ago suddenly changed it's behavior on multi-part movies. It now ignores any "folder.jpg" "poster.jpg" "backdrop.jpg" "fanart.jpg", etc. and only recognizes "Star Wars (1977) - Part 1-poster.jpg" "Star Wars (1977) - Part 1-fanart.jpg", etc. And it will download/create these files, with sometimes unpredictable results (the poster I intended or created, "folder.jpg", being ignored, and replaced with Emby decides is the closest match, which isn't always a match, especially with non-Hollywood movies).

Also, on these multi-part movies, Emby formerly displayed a screen grab for each of the additional parts, but now it displays the movie poster ("Star Wars (1977) - Part 1-poster.jpg") for Part 1 for all of the additional parts, which is far less useful.

I understand that some major changes/updates to Emby are being worked on, so I've managed this problem with manual work-arounds, but with these coding changes, Emby is definitely no longer working as the documentation suggests (or as I and many others would prefer). I'm sure these changes had some purpose originally, but the results are likely not what was intended. Hopefully this gets fixed on a future update.

[Luke 42083]

HI, this should be resolved in the upcoming 4.8 server release. Thanks.

@Happy2Play