[Finished] Reworking MP2's thumbnail building (1 Viewer)

[morpheus_xx]

It's time to rework the thumbnail building inside MP2. I want to address following "issue" we have now:

• IThumbnailBuilder is placed inside MediaPortal.Common assembly and uses the Microsoft API Code Pack. This brings 2 additionals assemblies to be placed in every related program (even service monitor)
• Thumbnail building always encodes as JPG. This is fine generally, but PNG thumbs are loosing alpha channel in this case.
• Video thumbnails are created by VideoThumbnailer plugin, based on ffmpeg.
  
• No "folder.jpg" is supported

My plan to make this more flexible is following:

1. IThumbnailBuilder remains inside MediaPortal.Common assembly, but only acts as "master" service
2. Thumbnail creation will be moved into plugins
3. Plugins will register themselves as "IThumbnailProvider"
4. Plugins will expose a "priority", so user could change priority of plugin to override execution order. first successful extraction result will be used.
5. Thumbnails will be rescaled in any case, if their size exceeds max limit (to be definied, setting?)

The architecture is similar to my FanartService, where plugins can register to add new media types.

I also like to add (again) support for "folder.jpg". My question is, if this provider should be always preferred over the shell thumbs?

My first idea about priorities would be:

• folder.jpg
• Shell thumbnail
• VideoThumbnailer (ffmpeg)

2nd question in this topic: do we really need two thumbnails (small/large)? I've added them to be able to use smaller thumbs inside large lists to reduce resource load (texture allocation). This idea is still valid, if we change our defaults for "large" to i.e. 512x512 or even 1024x1024. Small uses currently shell thumbs of max 96x96.

 

[MJGraf]

Nope, not true
storing the thumbs in DB is not slower than storing them in the file system. And if we stored them on the file system you would have to delete them if you recreated your database because the referring keys would have changed.
Backdrops e.g. Are stored in the file system - but tbh I don't like that...

 

[Lehmden]

Hi.

storing the thumbs in DB is not slower than storing them in the file system.

But in this case all thumbs were there already. So no need to store or generate them at all. And that definitely is faster a lot...
Poster, banner and fanart are there, so this won't be downloaded again. Only the thumbs are lost because of losing the DB.

 

[morpheus_xx]

Hi.

storing the thumbs in DB is not slower than storing them in the file system.

But in this case all thumbs were there already. So no need to store or generate them at all. And that definitely is faster a lot...
Poster, banner and fanart are there, so this won't be downloaded again. Only the thumbs are lost because of losing the DB.

We could implement 2 additional "MetadataExtractors":

1. One that is executed as last step (same as online access), which stores the already extracted thumbs back into filesystem (i.e. "a.mkv" -> "a.mkv.jpg") and
2. One that is executed as 1st/2nd step that checks for existing thumbs and adds them to Thumbnail aspect. Then all further thumb extractions are skipped.

This approach would have limitations:

• there are read-only shares / ISO / zip-archives could be imported, were writing back is not possible.
• the method describes has to be avoided for image shares, as it would create thumbs for thumbs for thumbs... in each run
• explorer cache would not be used (not an issue)

An already proposed alternative would be: https://forum.team-mediaportal.com/threads/reworking-mp2s-thumbnail-building.122807/, where a "folder.jpg" could be used as preferred thumb for all mediaitems of current folder. Please read this and share your ideas in the linked thread. Thanks!

 

[Lehmden]

Hi.

My first idea about priorities would be:
folder.jpg
Shell thumbnail
VideoThumbnailer (ffmpeg)

I think we need to separate Videos, Series and Movies as solitaire IA, not as Subset of Video IA as it is now. Later we could add another item aspect for MusicVideos (last FM metadata) and maybe Documentaries (don't know if there is an online DB for documentaries out there) and anime. Nice side effect would be the absence of series and movies in "Videos". So this isn't that crowded with 10.000nd of series episodes and movies which are much better be used from "Series" and "Movies" section than from "Videos" and I can find more easily what I'm looking for.

I really would love to see folder.jpg used inside MP2, but not necessarily as thumb- replacement... (see here also)

For Videos (all the stuff with no online- database) and for Movies (stuff with metadata from IMDB, TheMovieDB) we could (should) use folder.jpg. Also I would prefer to use folder.jpg as "replacement" for poster, not for thumb. That's how all other solutions are handling this. No matter if you use Ember, tMM, Moving Pictures, MyVideos, XBMC or whatever, always folder.jpg is the "preferred" poster for the movie inside this folder.

But on series with probably hundreds of episodes in a single folder this don't work. There we need Shell thumbnail (preferred, it's fast and most of the time already available) and/or VideoThumbnailer as source...

do we really need two thumbnails (small/large)?

I really don't think so. One should be enough. We could talk about the size and quality, but I really see no need for two thumbs for every Media Item....