You do get genre with OSMC but you’re right a lot of empty space there. Point taken.
1 Like
True, but I have to say: For a reason. I’m using the same spacing for all views to keep them consistent and to be able to show the same information in all views without cramming them on screen. It’s purely subjective, whether you like or prefer that, of course.
What Estuary does, which I don’t particularly like, is not keeping views consistent and placing information on top of other elements: See the media flags in the bottom right corner e.g.
The price for the OSMC Skin approach is however having to live with smaller poster fan art. 
And let’s now get this on topic again…
4 Likes
Even installing from this commit yields the same issue.
Perhaps, this gives some additional information: The logs from @Ainsley show, that the method ExtractThumbToTexture is called often. AfaIk this is done if the thumbnail is not present and the URL in the Textures database does not exists for this or is not available to download the image. The method ExtractThumbToTexture scans the video file to catch a picture for the video/the chapters which could explain the very longish duration.
Good questions are:
- Do an external URL and a local URL exist for the cover/poster/image in the texture database and is the local and/or external URL available?
- If the local URL does not exists, what is the reason for this?
- If the external URL is not available, what is the root cause for this?
- Why does it only happens with Estuary skin?
The kodi databases are just SQLite dbs, so apps like DB Browser for SQLite are your friends.
I followed @Ainsley’s instructions (except a fresh installation from an image) … and I can’t reproduce the issue as well on VeroV.
BTW: In the textures database is a timestamp field lasthashcheck. So, for the affected people: Is the displayed time in the GUI correct? Does the ouput of ls -ld /var/lib/ntp shows the owner ntp as user and ntp as group?
Yes and yes.
BTW, there is something else I think I never mentioned: if the drive where my media is stored is not connected to the vero, either when disconnecting it from USB or not available over network (as I’m using autofs with smb), the issue seems to disappear.
So basically like this:
- Connect drive
- Use OSMC skin
- Add movies library
- Wait until all thumbnails are availabe (which is almost immediately after the library scan finished)
- Disconnect the drive
- Switch to Estuary (wall view selected)
- Go into movies library and observe the thumbnail issue is not present
- Exit the movies library
- Connect the drive again
- Go into movies library and observe the thumbnail issue is immediately present again
I created some logs to show this. What I did: I switched to Estuary while drive was not connected, then I enabled logging and restarted the device. Then I went into the movies library and scrolled a little bit to confirm the issue is not present. Then I connected the drive and went into the movies library again to see the issue was immediately there. In the logs, every line from 2025-04-20 11:35:36.858 onwards is after I connected the media drive again.
Also, when the issue occurs, all thumbnails are affected, not only the ones of libraries, meaning even thumbnails for add-ons etc. take a moment to load when hovering over the add-ons main menu item.
This mimics the issues I reported some weeks ago. Both my Vero4k & VeroV are affected on the latest build (but not prior to this).
Was it faster before?
I wonder if there are regressions with a number of skins and it’s just more noticeable in some than others.
Sam
I can’t say.
I took a look at the texture table in the Textures13.db database. The table contains 2415 rows. Most of the URLs point to assets at image.tmdb.org, assets.fanart.tv, or mirrors.kodi.tv. I’ve tried a couple of them, and those images do seem to be available online. And, it’s not that the Vero is unable to retrieve the assets at all; it just takes a long time to display them.
Also, with the exception of the first two rows, which point to /usr/share/kodi/addons/script.globalsearch/resources/icon.png and /usr/share/kodi/addons/service.osmc.settings/resources/media/icon.png, the imagehash and lasthashcheck fields are all blank in my case.
Also also, the Vero’s clock is synchronised:
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
1.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
2.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
3.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
+ntp1.ams.nl.hoj 193.79.237.14 2 u 278 1024 377 11.823 +0.235 0.341
+178.239.19.60 ( 10.1.105.4 2 u 461 1024 377 16.225 +0.227 0.531
+178.239.19.57 ( 10.1.105.4 2 u 545 1024 377 16.225 +0.040 0.170
-mail.roundowl.t 192.171.1.150 2 u 771 1024 377 12.642 -0.440 0.511
+178.239.19.56 ( 10.1.105.3 2 u 394 1024 377 16.335 +0.166 0.477
*ntppool1.time.n .TMNL. 1 u 14 1024 377 15.758 +0.016 0.225
Hope this helps.
Responding to my own post because my earlier findings seem to have been erroneous. When the movie poster thumbnails are (slowly) being displayed, there IS a lot of traffic between the Vero and the NAS. I’ve enabled debug logging on the Vero and watched the log stream by in realtime as the main menu thumbnails are being refreshed. It turns out there is a whole lot of this going on:
osmc@osmc:~/.kodi/temp$ grep -i Marvel kodi.log
...
2025-04-21 23:13:58.057 T:3964 debug <general>: CFileCache::Open - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> opening
2025-04-21 23:13:58.063 T:3964 debug <general>: CSMBFile::Open - opened smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv, fd=10002
2025-04-21 23:13:58.067 T:3964 debug <general>: CFileCache::Open - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> source chunk size is 131072, setting cache chunk size to 131072
2025-04-21 23:13:58.067 T:3964 debug <general>: CFileCache::Open - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> using double memory cache each sized 33554432 bytes
2025-04-21 23:13:58.073 T:3985 debug <general>: CFileCache::Process - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> cache completely reset for seek to position 24386709510
2025-04-21 23:13:58.073 T:3964 debug <general>: CFileCache::Seek - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> waiting for position 24386830708
2025-04-21 23:13:58.330 T:3964 debug <general>: ExtractThumbToTexture: seeking to pos 2473856ms (total: 7421568ms) in smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv
2025-04-21 23:13:58.346 T:3985 debug <general>: CFileCache::Process - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> cache completely reset for seek to position 24386026573
2025-04-21 23:13:58.385 T:3985 debug <general>: CFileCache::Process - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> source read hit eof
2025-04-21 23:13:58.460 T:3985 debug <general>: CFileCache::Process - <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> cache completely reset for seek to position 8170628951
2025-04-21 23:14:28.701 T:3964 debug <general>: ExtractThumbToTexture: decode failed in smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv after 4161 packets.
2025-04-21 23:14:28.736 T:3964 debug <general>: ExtractThumbToTexture: measured 30679 ms to extract thumb from file <smb://192.168.111.16/media/Movies/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.HDR.Atmos.7.1-DDR/Captain Marvel 2019.MULTi.UHD.BluRay.2160p.HEVC.Atmos.7.1-DDR.mkv> in 4161 packets.
In other words: this particular thumbnail took about 30 seconds to retrieve, process and display. I did use iperf3 to measure the throughput between the NAS and the Vero, and it’s close the the maximum of 1 Gbps.
I realise that this is only showing the partial log and that a lot of crucial debug information is missing, but I just wanted to correct my earlier statement and show that slow processing of the video files from the NAS seems to by a factor here. A full log dump is available if needed, of course.
PS: I also checked the Textures13.db and MyVideos131.db databases to find the movie poster asset URL. It’s https://assets.fanart.tv/fanart/movies/299537/movieposter/captain-marvel-5c08e4b9bbb6f.jpg and it’s accessible online, so I have no idea why Kodi is trying to retrieve it from the video file (if it’s even in there).
2 Likes
… and why it only happens with the Estuary skin.
So, what happens if you disable the feature
settings -> system -> videos -> extract chapter thumbnails
with Estuary skin?
It’s under settings -> media -> videos by the way, but that’s okay.
I’ve disabled Extract chapter thumbnails there and Extract video information from files as well for good measure, but see no difference in behaviour; Kodi is still attempting to extract thumbnails from the video files on the NAS and it’s still taking seconds, up to minutes for each one.
I’m most certainly not a Kodi expert, but I don’t think the Extract chapter thumbnails feature affects the retrieval of movie poster artwork.
1 Like
As long as we cannot reproduce the issue, it’s hard to make any progress in getting a better understanding.
Last question from my side: Is this with all videos or only with those having a bookmark set or an resume point exists?
Fortunately, I and others are able to reproduce the issue, so feel free to have me do anything (within morally acceptable bounds) to get to the bottom of this. 
This is with all videos. I’ve never used the bookmark feature and only two videos in my collection are “currently playing” (i.e. have a resume point).
I will continue troubleshooting on my end and will let you know if I run into something interesting.
1 Like
If I read the source code correctly, the problem should not occur, if you disable “Extract thumbnails from video files” in the Artwork section of settings -> media -> videos.
Please, give this a try. I still have no idea why this happens at all and only with Estuary skin. There must be some special corner case as required condition we do not know so far … or someone has to dig into the Estuary skin code.
1 Like
But that would imply a change in Estuary to coincide with when everyone updated to the latest OSMC build. And since we updated OSMC at differing times that cannot be.
A code change in the latest OSMC build (although possibly at KODI level) has definitely changed something to cause the ongoing thumbnail issue. My library was unchanged for 3 weeks and the thumbnails were still being delayed in showing on screen (as reported by many others too), so it is not related to the initial thumbnail build but something in the code everytime they are displayed. It is as if it cannot access the thumbnail cache in a timely manner.
You, sir, have won the Internet today. Disabling that option does indeed seem to resolve the issue for me. Incidentally, it also fixes the “blue spinner overlay when starting playback” issue, and overall the interface feels a whole lot snappier because the CPU is not pegged at 100% all the time trying to encode thumbnails.
If there’s any additional debugging I can do to pinpoint the root cause, please let me know.
2 Likes
But does this then stop newly scanned videos from having Thumbnails extracted and displayed?
Where are these thumbnails from the video material used at all? I only know from the bookmark feature you only reach with the OSD. AfaIcs, all other is coming from the scraper.