[Forage]

Individual DVD VOB files are being imported as separate movies when performing a library scan since PR:5343 has been included in Kodi.

It is causing existing library entries of DVD copies, as well as new, to be included again on a rescan with all containing VOB files to be added as separate movies. The movie name of the VOB files is being determined based on the file name, thus resulting in a massive list of bogus entries in the library.

Folder structure (excluding IFO and BUP files for simplicity's sake):

Code:

\Movie Name\
    VIDEO_TS\
        VIDEO_TS.VOB
        VTS_01_0.VOB
        VTS_01_1.VOB
        VTS_01_2.VOB

Result:

• "Movie Name" is added by that name as a movie twice, as the first item and as the third item after VIDEO_TS.VOB being added as a movie
  
• All .VOB files are added as separate movies, three by the same name (VTS...) and 1 individual (VIDEO...)
  

Files are located on an NFS share.

I've first raised the issue in the RPi test build thread earlier. A build without the PR mentioned above fixed the issue.

[DaVu]

Thats why i dont use a dvd/br file structure in movie folders. I always use containers (mkv, iso) which containing those structures and are named as the movie. No problems for years and till now with none of the xbmc/kodi versions

[takoi]

Care to do a double check that it's 5343 and do a debug log? I can see how "scan the entire subtree of path passed to scanner" can be misunderstood, but we are in fact only talking about when updating library from builtin and json-rpc. Using "Update Library" from GUI should be untouched, which is why it sound odd that this PR would cause such issue.

Edit: I've been trying to reproduce for a bit but unable to get duplicates so far. Please provide a complete folder structure (I'm not sure I got it right) and steps to reproduce.

[Forage]

Care to do a double check that it's 5343 and do a debug log? I can see how "scan the entire subtree of path passed to scanner" can be misunderstood, but we are in fact only talking about when updating library from builtin and json-rpc. Using "Update Library" from GUI should be untouched, which is why it sound odd that this PR would cause such issue.

I can provide a debug log of both build #1111 and build #1111b if that's what you mean by double checking. The first build includes the PR, the second does not (being the only difference between the two builds).

FYI: what I used to trigger the library update was "Scan for new content" from the source context menu in the "Video's - Files" section.

[takoi]

Sure. You can start with the "broken" build. And post the folder structure (not excluding anything) so I can see if I can reproduce.

[Forage]

Sure. You can start with the "broken" build. And post the folder structure (not excluding anything) so I can see if I can reproduce.

Will do as soon as I get home later this afternoon. Any specific debug components I need to enable besides the main debug setting?

[takoi]

Sure. You can start with the "broken" build. And post the folder structure (not excluding anything) so I can see if I can reproduce.

Will do as soon as I get home later this afternoon. Any specific debug components I need to enable besides the main debug setting?

No. no extra components necessary:)

[Forage]

The folder structure of the DVD folder, located directly in the root of the movie source:

Code:

De Sint/
└── VIDEO_TS
    ├── VIDEO_TS.BUP
    ├── VIDEO_TS.IFO
    ├── VIDEO_TS.VOB
    ├── VTS_01_0.BUP
    ├── VTS_01_0.IFO
    ├── VTS_01_0.VOB
    ├── VTS_01_1.VOB
    └── VTS_01_2.VOB

• Log of scan with build #1111, including the PR: http://xbmclogs.com/show.php?id=349666
  
• Log of scan with build #1111b, excluding the PR: http://xbmclogs.com/show.php?id=349671
  

Let me know if you need any more information.

[DaVu]

It´s just a gues...but if I try to understand the settings in the source, there is a point, that is called "scan recursively"...

If you got a folder, which is named as the movie title, and have a DVD file structure underlying this folder, I would disable recursive scan, so that the scraper stops scanning at the folder and "ignores" the files underlying to the folder. So, if I understand correctly, the scrapers "sees" the folder (which has the movie title) and doesn´t "see" the files under that folder which might get this to work.

So, for a try, my setting for the source would look like this:

• Movies are in seperate folders that match the movie title - YES
  
• Scan recursively - NO
  
• Selected folder contains a single video - NO
  
• Exclude path from library updates - NO
  

Edit: I don´t know for sure, if "Selected folder contains a single video" is meant for the source (as you have to select it) or if it is meant for the folders underlying to the source. Maybe I would try to play with this point as well. But I suppose, it is meant as the source folder and means, that the source only contains a single video. So disabling this point, might be correct.


I can´t see something in the log if you already set up the source like this, so please apologize, if you already did and ignore this posting .

[EyeCandy]

I just found this thread after posting in someone else's thread at http://forum.kodi.tv/showthread.php?tid=208782
We are both having this problem.

[brucetheloon]

Can confirm I have experienced this problem after upgrading Kodi 14 beta 1 to beta 2. Reverting to beta 1 stops it happening.

Never had it happening on Frodo or Gotham.

Edit: While cleaning up the duplicate entries, found that the .IFO files were being indexed as multiple entries for the same movie title, but there were a number of entries for a movie called Benny's Video (1992) that had the VIDEO_TS.VOB file from each of the duplicated movies as its file

As Alice would say, curiouser and curiouser.

[brucetheloon]

I've dug through VideoInfoScanner.cpp which was patched by the PR:5343 and I wonder if what has happened is that a weakness in the movie scanning function hasn't been exposed by the changes made in the patch. The EnumerateSeriesFolder function at line 663 has a protection check for DVD folders at line 737 that if it detects a video_ts.ifo file, it removes all other entries for that folder from the working list. As far as I can tell, that is the only place where that is done and therefore a movie adds all the other files in a DVD folder.

I wonder if adding the protection check from 737 into RetrieveInfoForMovie might solve this issue.

[takoi]

brucetheloon: I have no idea what you're talking about. None of those line numbers make any sense for current master.

Anyway, hopefully fixed with PR5734. Thanks for reporting!

[brucetheloon]

takoi: My apologies for the line numbers being wrong, I ended up on another developer's master tree instead of the xmbc master. The code in your patch what I was referring to, so hope it works.

I'll give it a test when the PR goes into the master and a nightly build with it is available.

[takoi]

I'll give it a test when the PR goes into the master and a nightly build with it is available.

If you know how to compile and pull patches please help test and report before so people deciding can be confident it works as expected and doesn't break anything else