Local 'Scraping'

I found this thread while looking for comments on the same idea as the original poster.

I'd also want to have/code a way for XBMC to only use local nfo files, without a backing online provider. As XBMC supports nfo, it feels natural to me to be able to only use those.
That would assume that only "full" nfo (e.g. the ones created by an export) are used, the mixed or url ones would not be supported.

I see at least 2 advantages to this:
1) You have external control of what info are included in the library (whether by hand-editing the nfo or using 3rd party tools)
2) You have external control of what is actually included in the library (no nfo -> no import in library)

I'm ready to code this.
My approach would be to add a "Use Local info only" option in the category selection dialog. Enabling it would disable the scrapper selection list (and actual online scrapping in the backend, of course)

Would this patch be accepted?

Not sure if i like the idea about yet another GUI option but i think there's no way around it if we want to disable fetching meta from the net and only rely on local exports. So yea, i think it would be accepted.

Another option would be to add a static, not addon backed, "Local info only" in the scrapper lists.

That would be probably nicer and more logical from an UI point-of-view but dirtier in the code...

How would it be dirtier code-wise? From what i had in mind the user chooses a "local importer" scraper. As long as there's a full nfo, the scraper code should not try to fetch something from the web. Note, this is only theory Will have to try it later today.

You mean an actual scrapper addon doing nothing, right?
Problem I see is that it would still try to import files without nfo, leaving "blank" entries in the library, while I'd try to avoid that.

What I meant is adding an entry to the scrapper list which would be backed by code, not addon.

Anything wihtout an nfo file wouldn't be added at all, because there wouldn't be a real database of info to get any info from, thus no entry.

This actually sounds like a really easy and clever solution to the request, which is a somewhat common request too.

Mmm... Are you sure of that?

When my current movie scrapper doesn't find an entry in its database, a blank entry is still added to the XBMC library, with no other info than the filename, which is actually desirable in this instance, as it reminds me to update the entry.

But it is maybe scrapper dependent?

---

BTW, there is a ticket (4 yrs old !) for that which also proposed the "null" scrapper solution: http://trac.xbmc.org/ticket/5382

(2012-07-21 10:46)vdrfan Wrote:  How would it be dirtier code-wise? From what i had in mind the user chooses a "local importer" scraper. As long as there's a full nfo, the scraper code should not try to fetch something from the web. Note, this is only theory Will have to try it later today.

I tried to do this a while back just out of curiosity. One issue I found was that you still need to have a valid URL in CreateSearchUrl to pass to GetSearchResults. I managed to get around it by using the file:/// protocol to point to a non-empty local file - it worked, but there was no way I could see to make it "just work" for everyone without them having to set the path manually. (I had hoped the internal special:// protocol would work, so the dummy file could be stashed with the scraper, but alas no.)

Oups... I'm not familiar with XBMC ui but it seems going the "add an option" way would break all the skins, right?

Better to go the pseudo-scraper way, then...

And here is the pull request: https://github.com/xbmc/xbmc/pull/1192