[dteirney]

I've been working on a patch to allow myth:// recordings to be able to be added to the Video Library (http://trac.xbmc.org/ticket/7197)

To do this I've altered the VideoInfoScanner to check the VideoInfoTag associated with the Item, and if the season and episode number or original air date have been set, use those rather than parsing them out of the filename using regular expressions.

However, there seem to be a number of places where there are assumptions that only the filename is used for scraping.

Current problem is when the TV Show has "Refresh Information for All Episodes" chosen from the UI. This goes through the motions and the myth:// folder details are pulled from the directory cache. The cache doesn't store the associated VideoInfoTag information that the myth:// directory injects though so all Episodes are subsequently removed from the library.

Any ideas for the best way to move forward for this

[dteirney]

I'm confused by the IDirectory interface.

SetCacheDirectory() implies that DIR_CACHE_NEVER is the default, but then the default implementation of GetCacheType() returns DIR_CACHE_ONCE.

It looks like the DirectoryCache uses the GetCacheType() method call to determine whether to cache or not. And, most filesystem implementations override GetCacheType to specify what to cache and what not to cache.

If that is the case, why would someone use SetCacheDirectory()?

[jmarshall]

Perhaps the cache should store the info tag stuff that you set?

As for the IDirectory interface, the default is DIR_CACHE_ONCE - this means the dir goes into the cache on read (so that subsequent CFile::Exists() lookups are cached), yet another directory fetch will clear the cache prior to re-reading (i.e. directory reads aren't cached - only file lookups).

The SetCacheDirectory() is used to set the cache behaviour to something else (such as DIR_CACHE_NEVER, or DIR_CACHE_ALWAYS). The comment is simply out of date (will fix).

Cheers,
Jonathan

[dteirney]

It looks like the various info tags are supposed to be transient based on the current behaviour within FileItem.cpp.

Easiest options seem to be:
1) Change the filename format returned by myth:// for TV Shows to have the original air date burnt in them so existing scanning behaviour works using the Regular Expression parsing. At present I don't think I know enough to start messing around with cache behaviour.

So a URL might look like myth://192.168.1.3/tvshows/Mythbusters/1002_20090606123456.mpg#2007-06-01 (or some other format that will parse the date in VideoInfoScanner and not screw up other code outside of CMythFile and CMythDirectory).

2) Sort out how to never have the tvshows directories end up in the cache so the VideoInfoTag is always injected.

[dteirney]

@jmarshall: is it correct for CUtil::GetRecursiveListing() to not specify the DIR_CACHE_TYPE and have it default to ONCE even if the Directory source has specified something different?

It seems like it would be preferable for the Directory implementation to define how it should be cached rather than the Util class.

That Util class is used by the VideoInfoScanner and it looks like that might be where the caching is going awry for the myth:// directory even though I have specified not to cache internally through both SetCacheDirectory and GetCacheType.

[elupus]

Fixing the url for the scanner seems a bad idea. Making sure the scanner can use info tags set from the IDirectory retrieval seems like a much better way.

[dteirney]

Fixing the url for the scanner seems a bad idea. Making sure the scanner can use info tags set from the IDirectory retrieval seems like a much better way.

Yes, you're right.

I'm getting pretty lost trying to figure out why the caching is happening though. I think I've told it not to in CMythDirectory.

Is anyone else able to help? I believe I need to either specify a directory path that shouldn't be cached or alternatively store any VideoInfoTag information along with the FileItem within the DirectoryCache.

I think to store the VideoInfoTag in the cache requires a copy constructor to be used.

I'll post a tidied patch tomorrow and hopefully someone can shine some light on where I'm going wrong, or what I should do next.

[spiff]

videotag is most certainly stored in the cache - see ::Serialize()

[dteirney]

videotag is most certainly stored in the cache - see ::Serialize()

Here's the code pathway I think is causing the problem. I don't have a full debug environment that I can step through though so this is speculation. Easy to navigate through the code with Eclipse CDT.

CVideoInfoScanner::EnumerateSeriesFolder (with a folder)

CUtil::GetRecursiveListing (to get the files)

CDirectory::GetDirectory (without specifying any cache setting so DIR_CACHE_ONCE is used)

Eventually CDirectoryCache::SetDirectory (assuming not already cached)

CFileItemList::Copy

for (int i = 0; i < items.Size(); i++)
{
CFileItemPtr newItem(new CFileItem(*items[i]));
Add(newItem);
}

CFileItem::CFileItem(const CFileItem& item): CGUIListItem()
{
m_musicInfoTag = NULL;
m_videoInfoTag = NULL;
m_pictureInfoTag = NULL;
*this = item;
}

Is Serialize called automagically with the *this assignment? I can't see any other way how Serialize is called through that pathway. What am I missing?

[spiff]

the cache is a serialization of the fileitemlist

[jmarshall]

Seems strange to me - I don't see where the cache is actually being used here (other than setting the directory which makes a copy for the cache and doesn't touch the items).

I'd suggest stepping through the code if you can (nasty, I know!)

Cheers,
Jonathan