[sebak]

I do think it will be useful for a meaningful amount of the users, I don't know if English is your mother tongue

Also a Flemish speaking Belgian computer science student (but from the city with cheaper beer ). And indeed it might be nice to have a Dutch plot (mainly for my parents) and everything else from imdb. The way you explain it I can see it being usable, as long as people can also download all-in-one scrapers (which of course can still work with modules behind the curtains).

About the speed: I think the current scraping is all done by a single thread (correct me if i'm wrong, but I believe I read it somewhere), maybe there are opportunities for parallelisation.
And actually it's not the scraping that really annoys me, it's the looking for file changes. Some watched folders feature could improve this, but I don't know how feasible that is with all the different file protocols xbmc supports.

I too have knowledge of recommender systems ( did a project on it for university and had to read a lot of research papers on it ) and you are only partially right about the cold-start problem. There are solutions and workarounds. A recommender system is not the focus of this project, it's an example of what 2-way communication would allow us to do. I don't think xbmc will ever build one but existing once could use xbmc to acquire more data. One user's library will indeed probably not suffice but that's the reason a feedback channel would be implemented.

Okay, nevermind, I got this all wrong, I thought the feedback was from the user to the scraper (eg when the scraper presents multiple options of found movies and the user selected the best fit) instead of from the scraper to a service.

[dzan]

I do think it will be useful for a meaningful amount of the users, I don't know if English is your mother tongue

Also a Flemish speaking Belgian computer science student (but from the city with cheaper beer ). And indeed it might be nice to have a Dutch plot (mainly for my parents) and everything else from imdb. The way you explain it I can see it being usable, as long as people can also download all-in-one scrapers (which of course can still work with modules behind the curtains).

About the speed: I think the current scraping is all done by a single thread (correct me if i'm wrong, but I believe I read it somewhere), maybe there are opportunities for parallelisation.
And actually it's not the scraping that really annoys me, it's the looking for file changes. Some watched folders feature could improve this, but I don't know how feasible that is with all the different file protocols xbmc supports.

Beer in villages will always be cheaper Parallelisation is of course an option but at first the threading will be done in xbmc not the library. XBMC will do stuff like lib.init(scraperlist), lib.getPlot(path),...

[pecinko]

About your suggestion of removing the difference between a library view and a file view; this is beyond the scope of my proposal.

Sure.

I myself find the file view rather useful sometimes but I can see the improvement in what you suggest too.

Heh. If I'm not missing something you are another "victim" of XBMC duality approach Your "files" are still there in my proposal they are just scanned into library so you can, say, have your vacation videos in separate DB and be able to use it in more advanced way that just by browsing through folders

OTOH, if I added folder and said it contains movies I would expect that everything found there end up in library. Currently XBMC saves me from myself by skipping movies that by it's logic don't fit.