I would put myself in this camp, as well, although I would extend the idea to all the scrapers; it's annoying to change scrapers and rescan, not to mention the cumbersome process of changing each source's settings when you switch to a new preferred scraper.
To answer jmarshall's final question above, here are two different visions for the UX (my aplogies for the length, but I'd like to be as complete as possible):
First option: lower flexibility, easier implementation (call this the "FST" (i.e. "first","second","third") option):
1. Consolidate scraper options into a single location (central, not per-source). This is currently done (as of Eden) for music (System->Music->Library->Default ... service), but video scrapers are tied to individual sources.
2. That central location would be a "Metadata Sources" panel in the system settings, with a section for each scraper type. In a Confluence-style skin, this would mean a left-menu containing "Artist Info","Movie Info", etc., with the right-side list being the ordered list of scrapers.
3. Implement the "ordered list" as 3 settings: "First Scraper", "Second Scraper", and "Third Scraper", where each setting is an enum of the installed scrapers of a given type, plus 'none'.
By using the enum and fixed settings for "first", "second", and "third", we keep using all the same widgets, and internal code churn is kept to a minimum.
Second option: full flexibility with new setting/widget type (call this the "new-widget" option)
1. As with the previous option, I'd collect the scraper preference settings into a common location under the main settings
2. Add a new setting type "orderedenum" (or something similar) that pops up a list when selected; the ordered list would be populated by the set of currently-installed scrapers of the appropriate type, and the user could move entries up or down the list using the same mechanisms that are in place for the "Now Playing..." window.
By using the new setting/widget type, we allow all scrapers to come into play, and avoid stale settings if a scraper is uninstalled. There would be nontrivial internal (and skin) churn in implementing the new setting type, but it would be a fairly straightforward effort, and the results would be useful in more cases than just prioritized scrapers.
Now, the use cases:
1. Music
Music hardly changes. Currently the user goes to the main music library settings and configures a default scraper. This behavior would be preserved, save the fact that the user picks a sequence, rather than a default, scraper.
2. Video
When adding a video source, the user would only select a source type, rather than source type+scraper. This actually simplifies the process of adding or editing a video source, since it removes a chunk of complexity from the edit source window.
To set the scraper preferece, the user would go to the system settings instead of editing each source. I believe that this is more intuitive, since this makes video scraper selection the same as music scraper selection, and consistency is _good_ for UX.
Adding/removing scrapers:
1. When installing a scraper, it is immediately added to the lowest-priority slot on the list of that type. For the FST option above, this means adding it to the highest not-set option (or not at all if all three have been user-selected). For the new-widget option, this means adding it to the bottom of the list.
2. When uninstalling a scraper, it is simply removed from the list. For the FST option, this may mean shifting up (i.e. the second choice becomes the first choice). For the new-widget option, the entry is just removed.
Scraping data:
When scraping data, the system would do much like it does now -- pick the preferred scraper and attempt to fetch the data. The difference would be how it handles a "not found" failure -- previously it gave up, but now it would go to the next-most-preferred scraper and repeat the attempt.
To answer a few more of the original questions:
Q1. "How many services?"
A1. I'd say at least 3, although ideally it would be "however many are installed"
Q2. "If order takes priority, what happens if the first one contains useless information?"
A2. If it contains useless information, you get that useless information. This is how it works now. If you don't trust a scraper's data, put it lower in the priority list.
Q3. "How does the user then switch to the next one?"
A3. The user doesn't. If a scraper fails (can't contact server, entry not found, etc), the system falls through to the next scraper in the list. The user expresses a preference in the settings, and the system implements those preferences.
There are a number of other changes that could be implemented (e.g. merged data from scrapers), but a simple failover across a user-prioritized list would seem to satisfy the bulk of the need.
. I'm coming from "Music Section: Artist Info (how to scrape artist info automatically)" and I just experienced a strange problem when I wanted to add thumbnails for all my artists in the library.
