[dragonflight]

I must be doing something wrong, since it seems no one else has reported the problem (that I can find) and it does not seem to be a recent change (verified the same behaviour in Eden)

I have my movies stored in a multi-level heirarchy, in their individual folders and I scan in the files recursively and with movies in folders enabled
All is well, I have the metadata in library mode and in files mode.

I clean the library and in files mode there is no metadata displayed in media info mode, though if I display movie information it is there and library view is fine

The culprit appears to be

Code:

CLog::Log(LOGDEBUG, "%s: Cleaning path table", __FUNCTION__);
    sql = "delete from path where idPath not in (select distinct idPath from files) and idPath not in (select distinct idPath from tvshowlinkpath) and strContent=''";

This deletes all of the paths for the intermediate directories with the result that all of the ParentPathIds are invalid for the files in subdirectories

I thought I was just having finger troubles when stuf disappeared (I have been doing a lot of experimenting)!

Are movies not supposed to be in a heirarchy (makes scan recursive kinda silly)? I noticed in the code a comment about paths to directories not supposed to not have Content.

Before I submitted a bug/pull request I just wanted to check I wasn't being stupid (again)

mike

[jmarshall]

By the looks of it it needs the addition of the basepath stuff added in (c23 or so in movies). i.e. something like:

PrepareSQL("select c%02d from movie", VIDEODB_ID_BASEPATH);

Same for episodes, shows + mvideos.

[dragonflight]

So I still can't believe that this has gone unnoticed for so long.

I assume you meant to say parentPath as in VIDEODB_ID_PARENTPATH, that at least makes the database consistent - i.e. no dangling idPaths, but may not be the whole story.

After rebuilding my database (several hours - even with nfo's), I looked at my database and there were still 2500 path entries by a corrected delete from path ....

Most were paths with hashes for folders without videos such as subs and a few .Actors folders that are at least recoverable.

Unfortunately I went and "cleaned up" some of my database, so I am not quite sure what I did, but I got a few entries - some TV shows with scanRecursive, useFolderNames, strSettings, noUpdate, exclude set to 0.

I didn't have one in my database, but if you set a path to content NONE, and set exclude from scan then if that folder either had no scanned videos directly or only through sub-directories it will be in the path table with strContent='' and would get removed (as an aside it also won't get exported in a single file library export)

I tried changing the other settings and they all cause strContent to be set (at least for Movies)

adding "exclude != 1" to the query would at least save all non-recoverable info. As an alternative the database strContent could be set to "none" whenever exclude = 1 - this would also fix the problem of exporting the library (a bit of history: at first the indicator for excluded path was to set the strContent to none, that was changed (a3ba349e5e3174) to add the bool exclude, but no provisions were made to export it. As well a piece of code was missed, that should be fixed regardless, when scanning up the tree to search for a scraper, that checked to see if you were in an excluded subtree. There was a note about the possibility of confusion, but as "none" is never used (the string value for CONTENT_NONE is actually "unknown") I don't see the confusion and certainly not now with the addition of the boolean)

To be correct I think the query should delete anything not referenced (by idPath or idParentPath) and all default. Then anything not referenced should be checked for existence and deleted.

@jmarshall if you agree/disagree/comment I will write up the appropriate pull request.

[jmarshall]

Yup - the parent path is what I meant. Please do feel free to do up a patch for it and clearly describe the issues - it sounds like you're completely correct in the way to go.