[freezy]

Hey folks,

Just one thing I noticed yesterday while playing around with the Windows version of XBMC, so not sure if that applies to the Linux/Xbox versions too (will test when I get home).

When scanning all items of my movie folder into the library, I sometimes get several entries of the same movie. So I opened the videodb in a sqlite browser and found out that the dupe entry comes from the .IFO file that is part of the subtitles laying in the same folder as the .avi file:

movies/movie.title/movie.avi
movies/movie.title/movie.ifo
movies/movie.title/movie.idx (i think)

I'm pretty sure that the subs won't work if I just remove the .IFO file. I could however put them into a .rar file and enable "Search for subtitles in .rar files" (or similar).

Anyone else experiencing this?

[spiff]

very likely, stupid vobsubs. please open a trac for it

[freezy]

Alright, but I will still test it on Linux and Xbox before I report it.

Thanks for the fast response!

[freezy]

Same problem with Linux. Here is the trac URL: http://trac.xbmc.org/ticket/4488

[kraqh3d]

yeah this would likely affect all versions. the ifo file is being seen as a dvd ifo file. there are two ways to deal with this...

1) during the directory retrieval, have Xbmc remove the ifo file from the listing if a matching idx file also exists. this would be the more correct approach. if its not in the listing to begin with, it cant get into the library accidently.

or 2) as a workaround, modify the stacking code remove any ifo files if an idx file also exists. this will prevent the dup in the library as scanning relies on stacking, but the ifo file will still be present in files view if unstacked. but this is probably much easier in the short term.

[freezy]

Well since the problem is the library mode, I wouldn't mind having the IFO still around in file mode. So whatever suits you is fine for me!

[kraqh3d]

the problem is that xbmc includes in the listing. thus, the scanner finds it and you that duplicate entry in the library. though, is there any reason for arbitrarily named ifo files to be be displayed at all? why not just show video_ts.ifo and vts_*.ifo.

[freezy]

Yeah, maybe ignoring all .ifos but video_ts and vts_* will do the trick as well. Would this be the easiest way to solve the problem?

[kraqh3d]

not really. its just a clarification of how options 1 and 2 would be implemented.

[freezy]

Just came back from vacation and saw that it had been fixed. Tested it, and it works great now! Cheers, you are the best!

[kraqh3d]

its fixed in svn already? i've had a fix sitting uncommitted in my local sources for a week. a two part fix... first fix the scanner to stack them down to prevent duplicates. and second to stack out the duplicates that might pre-exist in the db during the retrieval. i was gonna commit it tonight. hmmm. i'd been rather busy and haven't synced in like 5 days. i'll have to sync up and review the log to see if i need to dump those changes.

[freezy]

I've only tested on Atlantis alpha 4 Windows release, and the scraping worked flawlessly with my .IFOs. But maybe without your part2-fix? Trac indicates the bug as closed however (last time I looked).

[kraqh3d]

nevermind. i just looked back at the entire thread, and you're problem was that vobsub "ifo" subtitles where causing duplicates. you didnt have dvd folder VIDEO_TS filesystem layout which causes duplicates (for each IFO and VOB.)

[tails_naf@yahoo]

Hi kraqh3d -
it looks like you've fixed the problem I've run into -
http://forum.xbmc.org/showthread.php?tid=36672

have you committed it? and if so, if I do a fresh build from svn, should I get to see these changes?

Any tips on a workaround - is it just a case of turning off the remove duplicates, or something more?

[kraqh3d]

yeah dvd folders are still broken for the tv show library. the fix is not in svn, but should be tonight.