Print

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

[MrHaugen]

1. No. Not with todays source
2. Yes. Somewhat
3. Yes. At a later time when I'm starting to use keywords

[glynor]

3. Yes. At a later time when I'm starting to use keywords

Specifically how.

Please keep in mind, [Keywords] are ALREADY BEING FILLED WITH SOMETHING.  And, you said that something was not useful.  How would changing that data source to something useful hurt you, since you don't like what it is being filled with already?  Now, you might not like the new data source for [Keywords] either, but you're still no worse off than you were before (again, it is already being filled with something bad).  This doesn't make any sense.

That's the point I keep trying to make.

You seem to be arguing that it shouldn't be filled with anything at all.  My point is that ship has sailed, and now it is being filled with something dumb.  Maybe you can argue that point, but that's NOT what we've been discussing all along here.

And, as Justin pointed out in the other thread, if you really, really, really don't want [Keywords] to get auto-filled you have a plethora of options.

[JustinChase]

1. NO!!!
2. Yes, one with some relevance is better than none
3. No

[bil1010105]

Please keep in mind, [Keywords] are ALREADY BEING FILLED WITH SOMETHING.

I can assure you that my [Keywords] are only being filled with data that I populate myself. Unfortunately, this means I cannot use the metadata scraping at all, in whatever form. Which is a bit of a shame really, as I've been looking forward to it for years and I never imagined it would target my beloved Keywords field quite so ruthlessly. Never mind, my yukky solution will do as a workaround if I have to.

And, as Justin pointed out in the other thread, if you really, really, really don't want [Keywords] to get auto-filled you have a plethora of options.

Can you point me at the "other thread" please, because I'd like to see some of that plethora. Thanks.

EDIT:

Btw, my options are:

1. NO!
2. Yes, but we all wish for something better one day.
3. Yes - although I've just read your reply & potential solution and slapped myself in the forehead a couple of times. Ow! Thanks for that... that solution is much cleaner. 

[glynor]

I think you figured it out, but I meant this other thread.

[maid]

Next build:
Changed: TMDb lookup gets genre for movies.

It'll get the first genre.  Switching genre (and artist) to a list may happen someday, but not today.

Can we also get a rating like the one IMDB???

[chinchin]

Currently ripping my DVD collection, my opinions are.

1. No
2. Yes
3. Yes

Remarks to 3:
Media management wise, I come from photo side of things and Keywords are traditionally used for individual tagging of files. Keywords and especially nested Keywords gives the user a fair deal of flexibility in regards to tagging. Filling out the Keywords field from an external source just seems wrong; I'm not sure who really is getting any use of this. My first action after importing a movie is to delete the keywords.

[fitbrit]

I think we're all a little confused.

Can I just ask a few questions to the people in this thread.  Can you try to give me yes/no answers as much as is possible so that we can get a clear answer on this?

1. MC is currently filling the [Keywords] tag with TMDb's Plot Keywords field.  Is this useful for you? (No)

2. Ignoring [Keywords] for right now, the proposed change would fill [Genre] (a string-type field in MC) with the first genre tag for each movie on TMDb.  This means that Harry Potter and the Deathly Hallows Part 1 would get tagged as [Genre]=Adventure (assuming the API returns them in the same order as they display on the site).  Will this work for you?  (No, I'd rather not potentially have movies in a series end up in different genres. A bit better than nothing though)

3. Instead of filling [Genre] with this first result, would it break anything for you if MC instead filled [Keywords] with all of the Genres in TMDb?  Keep in mind, [Keywords] is already being filled with something, so we're just talking about changing the source of that data from TMDb's Plot Keywords over to TMDb's Category: Genre tags.  (No, this would be great, unless we can have [genres])

[TMA-1]

1. No

2. Yes, better then nothing but not ideally.

3. No, but not ideally.

In MY world the ideal scenario is to change the genre string-field to a list-field (multiple genres) and fill it with all the genres from TMDb.
Besides that I believe the most logicall choise would be to have Genre in Genre and Keywords in Keywords.
But thats me =)

[rick.ca]

That was essentially rick's suggestion back when it was first implemented.

After reading this topic through, I have to wonder...Do you still think my suggestion unworthy of consideration because it violates the design premise the program must work out-of-the-box without any configuration?

This topic of two days and 58 posts (so far) is about filling TWO fields from ONE source, and it's full of confusion and disagreement. Even those who claim to be happy to have [Genre] filled with first term of TMDb [Genres] are likely to change their minds when they see the results. And it still doesn't address combining data from multiple sources. Why is [Keywords] rendered useless because one source has something vaguely similar? It's easy to conclude it's useless and should be dropped, but what if someone wants it? My point is this is just going to become an even more convoluted mess—for the sake of the weak premise it's necessary to standardize field mappings so those fields can be used in standard views.

My suggestion was all data elements could be mapped to stock fields unique to the source. That completely eliminates any confusion or conflict. It doesn't even matter if a user wants the data or not—it can't do any harm. It does leave the problem of how to present that data, possibly with that from other sources, in views. It would still be possible to create stock views that use expressions to combine the data in any manner desired. That could be in exactly the same manner as would be the case using the current approach.

The differences in the two approaches are enormous. My approach...

• As mentioned, completely eliminates all the conflicts and confusion cause by arbitrary mappings.
  
  
• Doesn't mix data from different sources that's similar but different (e.g., the single genre of one with the multiple genres of another, or short and long descriptions).
  
  
• Can retain the association of the data with it's source, making it possible to update the data as it's updated by the source. No data sources make all the data available at once and never update it, yet that's what the current approach assumes. Not sure if the data from one source is complete and up-to-date? Select the files in question and update them. That can't be done if the fields used include data from other sources and/or the user.
  
  
• If there are no potential conflicts or update issues, the user has the ability to map two or more sources to one field (with appropriate overwrite settings)—if the result is considered easier to manage. As we can see from this and similar discussions, whether or not that is so depends on the user's circumstances and preferences.
  
  
• Stock or custom expression fields can be added to combine or choose data from fields dedicated to specific sources. So even if the stock views must be as simple as possible, they could refer to such expression fields instead of being further complicated by using expressions directly.
  
  
• Stock views can still be presented, but they're not "carved in stone." The user can modify expressions in the Theatre View configuration to change how data is combined and presented in views. In configuring a custom view, there would never be any question of where the data in available fields comes from.
  
  
• The effort going into resolving unresolvable conflicts could be directed to making the Theatre View configuration easier to understand and use.

[MrHaugen]

You have some good points again Rick. Either this or your suggestion of saving all data in a "cloud config" and enabling users to change the default mappings to what ever. If I understood your suggestion which Glynor mentioned in the other post... Both suggestions would be miles ahead of what we have today, and would prevent a lot of posts, requests and irritation later on.

I look of this subject like I did with the "Tag on import rules" discussions and requests. This is a subject that will never die. It will be brought up again and again, and people will never stop complaining. Because users have so different wishes of what info to get, where to get it from and how to store it. If we are ever to hope of taking the XBMC users to JRiver MC, this is something that will be a constant question. Because XBMC users have so much freedom to get data from where ever they like today. You can be sure that there is users that will not like to be locked to 1-2 sources with a small predefined set of fields updated. It would be a good idea to let the users have some control of how data is fetched and mapped sooner than later imo.

[struct]

After reading this topic through, I have to wonder...Do you still think my suggestion unworthy of consideration because it violates the design premise the program must work out-of-the-box without any configuration?.....

+1 to rick.ca's suggestions.  Mapping and simplicity are not exclusive.  IF the default mapping is done well (and it should be to build default views around), it works out of the box.  If we want more, we go to a dialogue.  Is this not simple??  Much better than the program unable to do what is wanted.

Please, please, please allow mapping.

Thanks
Craig

[CountryBumkin]

No
Yes
No

[darichman]

It just seems to me that we're trying to force a fit here.
I agree with everything Rick says
  - Field mapping would solve every issue in this thread so far
  - I could say 'get me genres but don't get me keywords'
  - I could say 'only fill it in if it's empty' or 'always overwrite'
  - If I have other uses for these fields I can specify another field
  - J River wants to leave genre as a string? No problem - put my list of genres in my custom 'Genres' field. Then everything won't just be tagged as 'action' and 'adventure'.

As far as the topic issue, or default settings
  - I think Genre needs to go to a genre field.
  - I think Keywords needs to go to a keywords field.

The problems?
  - Mixing terminology is confusing and non-intuitive
  - People may have other uses for these fields
  - I, like bil1010105, find unassigned very important, as it shows files I haven't processed yet

[Sandy B Ridge]

It just seems to me that we're trying to force a fit here.
I agree with everything Rick says
  - Field mapping would solve every issue in this thread so far
  - I could say 'get me genres but don't get me keywords'
  - I could say 'only fill it in if it's empty' or 'always overwrite'
  - If I have other uses for these fields I can specify another field
  - J River wants to leave genre as a string? No problem - put my list of genres in my custom 'Genres' field. Then everything won't just be tagged as 'action' and 'adventure'.
As far as the topic issue, or default settings
  - I think Genre needs to go to a genre field.
  - I think Keywords needs to go to a keywords field.

The problems?
  - Mixing terminology is confusing and non-intuitive
  - People may have other uses for these fields
  - I, like bil1010105, find unassigned very important, as it shows files I haven't processed yet

Even though tagging and auto-metadata scraping isn't a priority for me personally, I have to admit that the opinions quoted above are very sensible and logical.

SBR

[JustinChase]

It seems the goal should be to get an acceptable "default" that "just works" for most people most of the time.

Then, give us the option to totally change it, as has been discussed and requested in about a dozen threads in the last 4-6 weeks.

I've seen Jim change his mind in the past; hopefully it can happen with this also.

[glynor]

After reading this topic through, I have to wonder...Do you still think my suggestion unworthy of consideration because it violates the design premise the program must work out-of-the-box without any configuration?

I didn't say it violated the design premise of "the program", I said that it would be ugly.  However, as that discussion progressed, I also said that your idea was a good one if they should choose to implement it.

To which Jim said "not now, maybe eventually".

I think that ship has sailed for this version. 

[fitbrit]

Even those who claim to be happy to have [Genre] filled with first term of TMDb [Genres] are likely to change their minds when they see the results.

Yes, you nailed it. Anyone who has part of their library already tagged with "genre" is going to have a rude awakening when they see what the first entry given by TMDB is. I spent 2 hours 'correcting' the [genre] entries last night of about 150 newly tagged movie files, and I still haven't been through all the "Drama" retrievals yet. Many of my new imports were Sci-Fi, but only three got tagged with "Science-Fiction". The Star Wars movies were not among them, for example.

[MrHaugen]

Can we also get a rating like the one IMDB???

The Movie DB rating is probably the closest we'll come without having options to select custom sources. TMDB rating is rather good. As long as enough people have voted. I hope this will get implemented after Genre. It's just as important as Genre, if not more imo. It's out in the open in the API, just like Genres. It should be a quick addition to today's scraping. We do however not have the Decimal Library Field needed for this. I would vote for adding TMDBrating as a Decimal field. And users can add the view if wanted.

However... To utilize this for new users, you would also need to add this as a stock view, and potentially destroy custom views. I hope JRiver have a plan to avoid this in the future. People don't like resetting views I think

[glynor]

Also, I don't think we need to keep answering my questions (though I was gratified that no one answered yes to #1).  That was done before Matt responded to my other request thread.

I will also say, from their perspective, I can see why they don't want to implement this now.  They're building a complex system built on "parts" that they don't directly control (because it uses multiple outside data sources) and they're doing it with a small team.  It makes some kind of sense that they don't want to introduce additional complexity right at the outset.  Keep It Simple Stupid and all that.

After they have a good, solid, foundation for the system, and they understand all of the problems that entails, they can enable a more advanced solution for edge cases and advanced users.  That's just how they built Red October.

That said, I also agree that people are going to be very hesitant to use this unless they can somehow "protect" certain fields (like Keywords and Genre) from meddling.  Some kind of setting that just blocks the Auto-Lookup on certain, user-specified fields, when this is turned on, will make it so those people can still use the system until some future "mapping" system is developed.

Otherwise, your only option is to turn it off.

[JimH]

The Movie and TV Info lookup should not overwrite any fields when it runs automatically.

If a user chooses to run it manually (by selecting files and right clicking), then it should overwrite the data.

At least, that's my understanding of our goal.  Matt may clarify.

[bil1010105]

I will also say, from their perspective, I can see why they don't want to implement this now.  They're building a complex system built on "parts" that they don't directly control (because it uses multiple outside data sources) and they're doing it with a small team.  It makes some kind of sense that they don't want to introduce additional complexity right at the outset.  Keep It Simple Stupid and all that.

Agreed.

After they have a good, solid, foundation for the system, and they understand all of the problems that entails, they can enable a more advanced solution for edge cases and advanced users.  That's just how they built Red October.

Agreed.

That said, I also agree that people are going to be very hesitant to use this unless they can somehow "protect" certain fields (like Keywords and Genre) from meddling.  Some kind of setting that just blocks the Auto-Lookup on certain, user-specified fields, when this is turned on, will make it so those people can still use the system until some future "mapping" system is developed.

Otherwise, your only option is to turn it off.

Absolutely agree. I'm in that camp.

[fitbrit]

I still want automatic meta data retrieval, but definitely do NOT want [genre] to be filled the way it is now. I think I'll be sure to add "unassigned" or "ZZZ" to all blank [genre] tags before looking up info on multiple files... until the current system is changed.

[rick.ca]

It makes some kind of sense that they don't want to introduce additional complexity right at the outset.

But that's exactly what they're doing. Implementing confusing logic and arbitrary handling of data when a direct and easily understood approach would work fine. Had they started with a mapping of fields defaulting to a stock fields designated for each source, then everyone could get used to just having the data without conflicts or mysterious handling. Directions for future development could then come out of some user experience with the data. That would likely include agreement that, while simple and direct, the sheer volume of data (assuming more sources are added) makes it overwhelming. Then, the added complexity of providing defaults that maps some data elements most would expect to be identical regardless of source to a single field, and that field used in stock views. Stock views, initially simplistic in structure with data presented by arbitrarily combining or choosing data elements from those stock fields, could benefit from the added complexity of providing more sophisticated expression fields for combining data—and using those in stock views.

It's not difficult to imagine moving in this direction, with incremental improvements that are easy to add and not very disruptive to users. But let's face it. There's no coming back from the current approach. That would involve throwing away much of the development effort, and require users to scrap their data and start over. This is not a unique insight on my part, and the direction taken must be a very deliberate one. So I fear those who feel Theatre View must not require any user-configuration and crave a WMP-like experience have won the day. I just hope it remains flexible enough we can continue to do our own thing.

[JustinChase]

While I don't necessarily disagree with this general sentiment, I don't think they've painted themselves into a corner with this.

I think the possibility certainly exists to get the current auto scraping system working pretty well, then add the customization to change what goes where, from where.  I think rick is right when he says that had the fully customizable path been pursued from the start, it might have been a shorter, simpler path to that end result, but people were screaming for automatic scraping, so that's what is being delivered.

Hopefully this road will continue to be traveled far enough to get to the fully customizable end result that we (the verbal ones) want.  Too often features/systems get 'pretty good' and then focus shifts away, and they never quite get fully 'finished off'.

[maid]

The Movie DB rating is probably the closest we'll come without having options to select custom sources. TMDB rating is rather good. As long as enough people have voted. I hope this will get implemented after Genre. It's just as important as Genre, if not more imo. It's out in the open in the API, just like Genres. It should be a quick addition to today's scraping. We do however not have the Decimal Library Field needed for this. I would vote for adding TMDBrating as a Decimal field. And users can add the view if wanted.

However... To utilize this for new users, you would also need to add this as a stock view, and potentially destroy custom views. I hope JRiver have a plan to avoid this in the future. People don't like resetting views I think

This rating is very important to me and would be great if it could be added somehow.