Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JustinChase]

TMDb has cover artwork that I usually prefer (less like movie posters, more like cover art), and also descriptions that I usually prefer (less about the making of, more related to the actual plot).

Rotten Tomato usually has more information, mainly Genre.

Someday, I'd like a way to 'customize' what information I get from where.  There are usually only about 9-10 fields in either service, and some are exact duplicates (Budget, Gross revenue, Director, MPAA rating, etc).

Ideally, I'd like to see something in the options that lets me select like so...

Field/tag          Service                    Include
[Description]       TMDb                        yes/no    
                          Rotten Tomatos         yes/no
                          Wikipedia                  yes/no

with "yes/no" being a checkbox, and allowing all to be unselected, but only one selected.  I will never want "Critic Rating" to be included, for example, nor "Keywords", other users probably will want these.

Uncommon fields would have to be dealt with, probably as a global "Include fields not listed above" or similar, in case someone wants all data they have available.  I wouldn't.

Theoretically, we could skip the results selection window altogether, and have a separate way to force it if we get wonky results.  Maybe it could still show, with results, and also show multiple cover art, like the "Get from Internet..." works now for Series/Episodes covers.

Thoughts?

[rick.ca]

This has already been discussed at some length in Wish for an Integrated Automatic Meta Data System and elsewhere. What we need is the ability to configure each source—to map each data element available to a specified field (which might be a custom field), and indicate whether or not existing data may be overwritten.

[JustinChase]

Perhaps.  There's lots of ideas there, all written before the current system was created I think.

I thought my suggestion/request was rather simple, given the current state.  I don't think it's the perfect system, but rather, a change I think has a chance of happening soonish, and would increase my usability of MC.

I'm not sure what you mean "configure each source", but whatever it means, it should not include expressions, or programming familiarity.  Most users won't know how, nor want to do any of that.

I see 15 or so data fields among the 3 current sources, 10 or so in each one, not all the same, some exactly the same.

Where they are the same, no choice is necessary.  Where one source has data and the others don't, no choice is necessary.  Where the same field exists in multiple places, I'd like to choose which to use.  My suggestion resolves this, in a manner that I think would be pretty easy to use.

I'm sure much better could be done, as your and glynors posts there indicate.  Joe user won't bother with either method though.

Whether or not to overwrite data is a good question, and another yes/no box could solve this in my solution above.

[rick.ca]

I'm not sure what you mean "configure each source", but whatever it means, it should not include expressions, or programming familiarity.  Most users won't know how, nor want to do any of that.

That's not a useful generalization. The system I recommended would work for everyone, would not cause frustration from unnecessary restrictions, and would be easy to use. Your suggestion simply won't work because...

I see 15 or so data fields among the 3 current sources, 10 or so in each one, not all the same, some exactly the same.

...you're assuming you can predict what fields all users will want to use for each source. You can't. If you tried to guess what fields I put TVDb data into, you wouldn't come close. Some of them are custom fields. That's not an uncommon need, particularly when multiple sources are being used.

I'm sure much better could be done, as your and glynors posts there indicate.  Joe user won't bother with either method though.

Once again, you're assuming something suggested by someone else must be motivated purely by interests no one else shares. In fact, those suggestions were carefully considered as an effective solution that would be easy for everyone to use. Assuming away the inherent challenges (e.g., that all data from different sources is the same and all users will want to put in the same fields and use those fields in the same way) doesn't make anything easier for anyone. Especially "Joe user" who, despite wanting everything to work out-of-the-box, will instantly see the limitations and be frustrated by the lack of any possible solutions.

[JustinChase]

...you're assuming you can predict what fields all users will want to use for each source.

I showed an example of letting the user specify what they want.  In no way did I state what I thought other users should have chosen for them.  Exactly the opposite I think.
I said...

Ideally, I'd like to see something in the options that lets me select like so...

Field/tag          Service                    Include
[Description]       TMDb                        yes/no    
                          Rotten Tomatos         yes/no
                          Wikipedia                  yes/no

with "yes/no" being a checkbox, and allowing all to be unselected, but only one selected.  I will never want "Critic Rating" to be included, for example, nor "Keywords", other users probably will want these.

I also said, in response to your first reply...

Whether or not to overwrite data is a good question, and another yes/no box could solve this in my solution above.

[struct]

Please no arguing on this topic.  We don't want JRiver to think there is no concensus on what we want     [not trying to say what it is exactly as I don't know what it is, I just know it is way better than I can write here and besides, I like to be surprised.]

There is no reason why the implementation of this feature need not be extremely flexible and at the same time very easy to use.  Afterall that his how the rest of the program works.  They are not mutually exclusive.  We should all start with this premise.

Leaving things half complete or without help is where we need the tweaking superuser and probably what JustinChase is worried about when reading the word flexible. It is not a problem with the system, just the final implementation.  An example of this is the Caption in theatre view.  Despite looking a little limited, with the use of super expressions, it is quite flexible.  But for me (not far from Joe User), it is quite useless as I can't be bothered writing a custom expresssion.  This is an example of a leaving a flexible feature incomplete and I for one don't want JRiver to set a scraping engine up and leave it for users to get their ultimate flexibility by writing configuration files.  But I don't think anyone here wants that.  It needs tick boxes, dialog boxes etc doing the common tasks, one of which JustinChase has mentioned.

I suspect we all want the same thing here guys, so no need to argue.

Craig