Hello
I'm looking for some guidance on how to handle a problem with a recently-installed My Movies Collection Manager 5.40 database.
You may want to get some popcorn before starting to read - it's a long story.
Data Welfare Statement: No data has (yet) been (permanently) destroyed in the making of this story.
Spoiler: Trying to import a folder full of movie stubs (empty VOB files), in order to allow creation of Kodi-compatible NFO files has removed all covers (and maybe other data) from my local SQL database. This loss hasn't propagated to my Android devices, or (as far as I can tell) the online copy at oc.mymovies.dk.
Ok - now the full story.
I had a collection of about 540 DVDs/Blu-rays created using the My Movies (v1) android app, mainly created around 5 years ago, but decided that I'd like to try to use Kodi to allow me to view the information by using stub files and NFO exported from MyMovies.
To test this out, I created a brand new instance of Win7 (64-bit) on a virtual machine, and installed My Movies Collection Manager 5.40 with Microsoft SQL Server 2014 Express SP3 and Microsoft .NET versions 2.0.5, 3.0,3, 3.5.3, 4.0 (Client) and 4.8 (Client + Full). This machine has absolutely nothing on it other that MyMovies and its prerequisites (so, worst case, if I neeed to, I can just nuke it and retry).
So, having synchronised the database (no major problems - quite a few minor issues, which I'll skip here and come back to at some future date), I tried to export the NFO data (having eventually found the "Update stored Meta-Data files for all titles in the database" button in the Settings menu).
This, of course, did nothing because MyMovies had no way to know where the data was to be saved (and didn't warn or ask, just popped up a dialog box claiming that it was saving each file, when it wasn't actually saving at all). Eventually I worked out that it was necessary to put a file location into the Location field of the "Personal Data", at which point an NFO file is created alongside the (zero-length VOB) stub file.
Further tests showed that the "File>Import>Folder Content" function successfully sets the Location field. I tested this out on a test folder containing just a few stub files (each in its own appropriately-named folder), and the NFO export appeared to work.
I then did this on a folder full of movie stub files that I created (based on an exported Collection.xml file) for my whole collection.
About half of these failed to match the version of the movie that was in my database, and resulted in the creation of a new database entry for each mismatched stub - not a problem, I deleted these (easily identified by their index numbers). These mismatched entries are not an issue (although I was surprised that it was about 50% of my collection - I'd hoped for fewer).
I ran an "Update stored Meta-Data files for all titles in the database" and the NFO files for the successfully-matched movies were all successfully created.
Unfortunately, I then realised that, in my local database, the covers for all of the files that had been successfully matched had been deleted. I ran another "File>Import>Folder Content" and compared the new Collection.xml file with the one that I'd created earlier.
From this, I found that, for each of the entries that had been matched, the following 4 changes (or very similar) had happened (please ignore the inserted space after each "<" - this was the least intrusive way I could find to post XML snippets in the forum, given its anti-XSS settings):
Code:
(1) Within < PersonalData> changed from:
< DiscLocations>
< Disc Name="Theatrical Version" />
< Disc Name="Director's cut" />
< /DiscLocations>
to:
< DiscLocations>
< Disc Name="Theatrical Version" TypeA="1" LocationA="Z:\Movies\The Wicker Man (1973)" />
< Disc Name="Director's cut" />
< /DiscLocations>
(2) Within < Discs> changed from:
< RegionCodes>
< RegionCode>2< /RegionCode>
< /RegionCodes>
to:
< RegionCodes>
< RegionCode>2< /RegionCode>
< RegionCode>2< /RegionCode>
< /RegionCodes>
(3) Within < Discs>
changed from:
< LocationSideA>
< /LocationSideA>
< LocationTypeSideA>3< /LocationTypeSideA>
to:
< LocationSideA>Z:\Movies\The Wicker Man (1973)< /LocationSideA>
< LocationTypeSideA>1< /LocationTypeSideA>
(4) Within < Discs> changed from:
< Covers>
< Front Width="1524" Height="2038">Covers\96f9c725-193e-4ecc-9fb5-25c169fb3b2a.jpg< /Front>
< Back Width="1524" Height="2059">Covers\419bd021-dbb0-4c20-9820-9a020187d4dd.jpg< /Back>
< /Covers>
to:
< Covers>
< Front />
< Back Width="0" Height="0" />
< /Covers>
Of these, (1) seems to be as expected, (2) seems odd but probably harmless and (3) seems benign. Change (4), however, is definitely undesirable. Fortunately, it does not seem to have been propagated through synchronisation.
I do have the logs for the period of time where this happened, but there are quite a few of them covering the proces, so I'll wait for guidance before posting these.
These changes only occurred for movies that had been matched to the stub files. Movies that hadn't matched were unchanged.
So, the questions I have are:
1. Is there an easy way to force a reversion to the good online version, or do I need to delete the database, create a new one and resynchronise?
2. Was my expectation of the behaviour of the import process correct (i.e. that it shouldn't clear the existing cover information)?
3. Is there another procedure that I should have followed to set the locations and create NFO files? (I searched widely but found nothing useful.)
4. I'm aware that 5.40 is a very recent release. Would it be safer to use an earlier version?
Thanks
fleasus