Thumbnail Extraction not Working

[srolomc 2]

I am currently running into an issue where the thumbnail image extraction task runs for less than a second and does not seem to do anything.  Here is the information for my Emby instance:

 

OS: Fedora 31 (using Docker container)

Emby Version: 4.3.0.30

 

I also have have both "Enable thumbnail image creation" and "Save thumbnail images into media folders" checked in each library, and I believe that permissions on the directories are correct.

 

Are there any recommended steps for debugging this besides looking at the log?  The log does not show any errors that I can see around the time where thumbnail extraction was initiated (enabled debug logging did not show any more information related to this issue).

 

The latest log where I tried running this is attached to this post.

 

Thanks for the help!

[Luke 36991]

Hi there, please discuss an example and see how to report a problem. thanks.

[srolomc 2]

Thanks Luke, here is what I am trying to do:

 

I wanted to have thumbnails on my Roku for seeking through video, so I selected the thumbnail options in my media libraries:

 

 

 

When I try to run the Thumbnail image extraction task, I see:

 

 

 The thumbnail extraction says that it only takes one second.  The log (attached to this post) only shows the following:

2019-12-01 15:37:30.753 Info TaskManager: Executing Thumbnail image extraction
2019-12-01 15:37:30.754 Info HttpServer: HTTP Response 204 to 192.168.1.27. Time: 5ms. http://192.168.1.21:8096/emby/ScheduledTasks/Running/1897e90bf232ef53a95bd5f5f523f8cd
2019-12-01 15:37:30.759 Info HttpServer: HTTP GET http://192.168.1.21:8096/emby/ScheduledTasks?isHidden=false. UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
2019-12-01 15:37:30.760 Info HttpServer: HTTP Response 200 to 192.168.1.27. Time: 1ms. http://192.168.1.21:8096/emby/ScheduledTasks?isHidden=false
2019-12-01 15:37:31.558 Info TaskManager: Thumbnail image extraction Completed after 0 minute(s) and 0 seconds

It appears that nothing is actually running when I try to run the scheduled task (at least from what I can see in the log), so I was just wondering if anyone else has run into this or if there is possibly any extra setup that I need to get this running.

[Luke 36991]

I can only guess that you may have had some files that failed to extract thumbnails for. Occasionally this may happen with certain files. @@Happy2Play can you link him to your instructions on how to check the contents of the failure file? Thanks !

[Happy2Play 8216]

@@Luke why is the Recorded Movies options different for Thumbnails above?

 

 

 

@@srolomc

 

Is there a "thumbnail-failures.txt" in your Emby cache folder?  You can see your Emby cache path on the Dashboard.

[JaScoMa 33]

Also check the thumbnail-failures.txt file within your cahce folder; /var/lib/emby/cache.

 

I had issues where it wouldn't create the files for movies and found them listed here.  Deleting the contents of this file will tell emby to try and re-create images for these failed shows, movies, etc.

[Luke 36991]

@@Luke why is the Recorded Movies options different for Thumbnails above?

 

 

 

@@srolomc

 

Is there a "thumbnail-failures.txt" in your Emby cache folder?  You can see your Emby cache path on the Dashboard.

He probably didn't use the toggle to show advanced options.

[miblo69 0]

Hi All,

 

I have the same issue as OP. Looking into the file thumbnail.failures.txt - I can see 54 of files failing. The strange thing is I have around 2400 files to be Thumbnailed, but around 95% of the thumbnails do not show up. Only a green/yellow/orange/red square.

 

I have organized my movies in multiple subdirectories - and I get a feeling only Thumbnails in the root directory are generated. I do have spaces and non-ASCII characters in both directory and file names, whihc have been known to cause issues on other systems (Piwigo comes to mind for Photos. Athough now it's mostly resolved).

 

But I am not seeing any error anywhere to give an indication of *why* the Thumbnailing fails. embyserver.txt gives no additional clues. And strangest of all - I can still stream the movies flawlessly. It's just the Thumbnailing that fails.

 

Let me know what you need and I provide for troubleshooting.

 

Thanks.

[Luke 36991]

we'd have to look at some examples of files that aren't getting thumbnails. thanks.

[srolomc 2]

@@Happy2Play

Sorry I haven't been back to the thread in a few days, work has been crazy this week; I do appreciate the quick responses. So I did check for the "thumbnail-failures.txt" file, I do not see one in the cache directory. Any other information I can provide to help debug the issue? Also I think I put it in the original post, but I am using the Docker container for Emby instead of the service.

 

Also, here is the thumbnail info with the Advanced options checked:

 

[Happy2Play 8216]

@@Happy2Play

Sorry I haven't been back to the thread in a few days, work has been crazy this week; I do appreciate the quick responses. So I did check for the "thumbnail-failures.txt" file, I do not see one in the cache directory. Any other information I can provide to help debug the issue? Also I think I put it in the original post, but I am using the Docker container for Emby instead of the service.

 

Also, here is the thumbnail info with the Advanced options checked:

 

 

Have you done a search in your /metadata/library folder for bif files?

 

Have you tried removing a item from your media folder, doing a library scan ensuring it no longer exist in Emby, then re-adding it and doing another library scan to add it.  The run the Thumbnail image extraction task?

 

I believe all the logging for the primarily resides in debug logging (server needs to be restarted when this option in enabled or disabled) as "quick-extract-imageseries" logs are only created with debug logging enabled.

[srolomc 2]

So it looks like for some of my libraries, the bif files are being stored in the metadata/library folder where you suggested that I look, but some of them are being stored in the actual media folders.  I did double check the thumbnail settings for each library, and they do appear to be the same.  The media in question are new files, so I did not try removing them and re-adding them since they are already new.

 

All in all it does appear that the bif files are created and present for the media in question, but I am not sure why they are being stored in the metadata directory instead of the respective media directories?

[Happy2Play 8216]

So it looks like for some of my libraries, the bif files are being stored in the metadata/library folder where you suggested that I look, but some of them are being stored in the actual media folders.  I did double check the thumbnail settings for each library, and they do appear to be the same.  The media in question are new files, so I did not try removing them and re-adding them since they are already new.

 

All in all it does appear that the bif files are created and present for the media in question, but I am not sure why they are being stored in the metadata directory instead of the respective media directories?

 

All I can really suggest is posting server log when you add a new item and perform the Thumbnail image extraction task.  But it sounds like a permissions issue as I am pretty sure almost all tasks will fallback to the /metadata/library folder when Emby can not write to media folders.

 

If bif files exist in /library, you would have to delete them for there to be regenerated in media folders assuming there are no permissions issues.

[Luke 36991]

Yes that's what will happen if you enable the option but the server is denied write access to the media folder.

[srolomc 2]

Ok so I think it did end up being a permissions problem, it's good to know that it will fall back to the metadata folder when there are issues like this.  I removed one of the thumbnail files in the metadata folder, re-ran the thumbnail task, and it generated and stored the bif file in the expected directory.  Thanks for the help guys! 

[Luke 36991]

Thanks for the feedback.