Bug #325
open
Good news to this: it is not an error of the scraper! I understood debug log and here is what it does:
If folder not in database:
if Found matching URL NFO file:
take url and fetch info
if result good:
continue with scraping of additional stuff like images
else:
die and go to next folder # Here we have our bad end
As an improvement I would suggest:
If folder not in database:
if Found matching URL NFO file:
take url and fetch info
if result good:
continue with scraping of additional stuff like images
else:
continue with name search the same way as there wouldnt be any nfo file. #This would fix #325
In other words: If I would delete all movie.nfo files it would success with good scrape rate.
If you can tell me were this algo is defined I can maybe fix this.
Okay the file is obviously named "VideoInfoScanner.cpp"
I'm sorry for the double posts, but I'm not able to edit.
The error is thrown because CNfoFile doesn't declare it as ERROR_NFO if url is bad.
In line 1517 you can find: else if (result != CNfoFile::NO_NFO && result != CNfoFile::ERROR_NFO)
it goes inside this although it has some kind of bad url or no url from nfo file.
Maybe NfoFile.cpp line 177 doesnt get all cases.
Hopefully you know some more about this code, but atm I'm glad that I could fix it with deleting nfo files ;)
Today I deleted all nfo files from movie folders and it worked flawless as expected, so the problem is obvious.
- Target version changed from 3.5 to Future / Pending
I now made a deeper bug tracking and the problem in all cases is that if for a MOVIE_NAME.EXT a MOVIE_NAME.nfo exists AND
MOVIE_NAME.nfo has an imdb url included THAN in VideoInfoScanner.cpp the code
case CNfoFile::URL_NFO:
type = "URL";
break;
becomes valid. The problem is here that the scrapers cannot handle this imdb url but try to and not fall back to title search.
As a solution I would recommend to completely delete the type URL_NFO for a CNfoFile as it can only generate problems as far as I see.
Also available in: Atom
PDF