Textures13.db - path table, how does it work?
#1
Can anyone provide a bit of background information on how the "path" table in Textures13.db is used and maintained?

It appears to be the first point of reference when displaying artwork that may already be cached, yet the table only appears to contain artwork for the top level folders and not individual items (eg. movies) within folders.

Is the intended purpose of the "path" table to speed up directory listings when in Files view, to avoid drilling into each folder to determine the relevant fanart/thumbnail?

In which case I can only find one point in the code where rows are deleted from the path table (calling CTextureDatabase::ClearTextureForPath, specifically removing "thumb" artwork yet I have "poster", "fanart" and "banner" artwork in my path table (in addition to "thumb"), which suggests these other artwork types will never be removed.

So it seems that a number of rows are added to the path table, but only the "thumb" rows are ever removed. Is this intentional, and if so, why?

And while it is possible to remove rows from the texture table, would removing a row from the texture table that is pointed to by a row in the path table ever cause a problem?

I'm just wondering if it's possible for the path table to ever become out of sync, as there seem to be a few gaps (certainly with my knowledge, possibly in the code) which might be a problem if the path table is the first point of reference and could lead to artwork not appearing which might otherwise be available.

How and when should rows be deleted from the path table - should rows be removed from the path table whenever the corresponding row in the texture table is deleted (this could be accomplished with a modification to the existing delete trigger, "delete from path where path.texture = old.url")?

Maybe one for @jmarshall... Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#2
So nobody knows how the path table works, or is it because I'm not a member of the secret society? Wink
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#3
It's because the guy that knows didn't see the post? Smile

The path table contains art for paths that isn't described elsewhere (i.e. in the video or music databases). The idea is that once we find art for a directory, picture, or whatever, we don't want to have to constantly re-look for it, so we cache the art URL that we found for that particular path in the path table.

The art URL in the path table would then appear in the texture table once cached.

You can delete rows in the path table without issue really - they'll be re-generated by the thumb loaders.

You can definitely have rows in the path table that aren't in the texture table (perhaps it hasn't been cached yet) so a trigger would not necessarily be appropriate.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#4
Thanks for responding.

(2014-03-21, 07:34)jmarshall Wrote: The path table contains art for paths that isn't described elsewhere (i.e. in the video or music databases). The idea is that once we find art for a directory, picture, or whatever, we don't want to have to constantly re-look for it, so we cache the art URL that we found for that particular path in the path table.

That's the odd thing, many (most, in fact) of the paths I have in the path table are for video and music paths. Pretty much every folder I have within my sources is present in the path table. There are also some non-source folders.

I'm guessing this path table is also useful when browsing the GUI in Files view, but having looked at the C++ code it appears that the paths table is always queried before the texture table, which might suggest a potential problem if rows are inadvertently missing from the path table (as then it might not go on to lookup the texture table). Is this possible, or have I just followed the wrong code sequence (quite possible). I'd always been under the impression that when displaying artwork for library items the rows could be retrieved directly from the texture table (via either the url or cachedurl), yet there seems to be an intermediary step via the path table in some cases.

I'm also wondering how rows are removed from the path table, if for instance someone where to remove textures from a folder, the references to the path and textures would remain in the path table even though the cached files (and perhaps also the original files) would no longer exist.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#5
Folders != movie or tvshows, right? So yeah, Files view. If they're also in the library then they're not even used in files view when stacking is enabled.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#6
Yes, only folders - not actual files. It's all for folders that are within my sources (both movies and music, plus a non-library smb path that has no content defined, I just use it for random stuff).

(Sorry about the quality of the screen grabs, you'll need to squint - I'm blaming the shoddy Microsoft snipping tool...)

Movies:
Image

I'm not sure what's going on with the "multipath" entries with the Die Hard textures - that's pretty messed up.

Music:
Image

Pretty much everything is fine, but the C++ code I higlighted takes the route of looking up the path table, then the texture table before loading the artwork from the cache, hence my question - what if the path table is ever wrong or becomes out of sync with reality? I don't have any firm evidence that there is a problem, just suspicions, and the C++ code I highlighted appears to be querying the path table when, given the information already present in the media library, I would have thought it was redundant and the texture table could be queried directly (unless I'm following the wrong code path!)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#7
(2014-03-21, 09:24)MilhouseVH Wrote: hence my question - what if the path table is ever wrong or becomes out of sync with reality? I don't have any firm evidence that there is a problem, just suspicions

Hmm, I -might- have a concrete example of something like that happening, though it's just a suspicion at this point...

I have a movie set which fails to load its thumbnail and fanart. Looking at the debug log, it's trying to load the images from a path that existed at one point, but has been moved elsewhere. The library has been cleaned and the movie has been rescraped, and is part of the movie set once again.

The thumbnail and fanart it tries to load belongs to one of the movies in the set, but when I enter the set, the movie in question correctly loads its thumbnail and fanart from the new path, only the set still tries to access the old path.
Reply
#8
If the path table points to a texture that's not cached it'll be cached. If it points to something that doesn't exist (and isn't cached) then it'll just fail to load - no big deal really. I guess one could check both path and texture tables when doing a GetCachedImage() and return empty if it is in the path table but not the texture table, but again you get the issue where this actually occurs pre-cache.

@sialivi your issue is unrelated. If you take a nosy through the art table in your video database you'll see the old paths referenced there.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#9
I had been looking in the wrong table, you're absolutely right. Problem solved. Now I just need to reliably break it in the same way again so I can report it as a bug Wink Thanks for the help, and sorry about the unrelated interruption.
Reply

Logout Mark Read Team Forum Stats Members Help
Textures13.db - path table, how does it work?0