Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actors - feature request #157

Open
KarellenX opened this issue Sep 11, 2022 · 4 comments
Open

Actors - feature request #157

KarellenX opened this issue Sep 11, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@KarellenX
Copy link
Member

Recently I have been undertaking a clean up of my library- deleting movies, rescraping others to update their data.

I noticed that out of 660 movies and 170 tv shows, I have a little over 38,500 actors listed in the database. I feel this is an incredible amount of actors.

Out of 38,500 actors, 14,760 (39%) do not have images. Most of these are the uncredited extras or one-time actors, and this is very noticeable when flicking through the movie information page, with all the blank actors images.
Out of the remaining, who knows how many have broken artwork links from the many artwork purges at TMDB, which will become apparent when I next rebuild my library.

My requests, which involve a couple of extra settings...

  1. When scraping actors data, if the actor has no artwork URL, discard that actor
  2. Option to limit the number of actors scraped per movie/tv show- 5, 10 or 20 or a user configured amount.

Maybe @pkscout and @romanvm could consider this for their scrapers also

It would also be nice to sort out that actors issue (is it a json-rpc problem?) so that artwork dump can also download actors images to the .actors folder

Thanks.

@KarellenX KarellenX added the enhancement New feature or request label Sep 11, 2022
@pkscout
Copy link
Member

pkscout commented Sep 11, 2022

I'd rather see these as settings in core. If a scraper discards data during scrape, the only way to ever get it back is to rescrape everything. If you have options in core to display only actors with images and/or only a certain number, that feels like a better choice to me, as you can enable and disable it at will.

A larger, longer term this would be to have a way to actually manage actors the way we manage TV shows and movies. If you could update an actor image or add one of your own, that might be useful. But, as you pointed out there are lots of actors, and managing tens of thousands of actors as individual entities would be a bear for sure.

@KarellenX
Copy link
Member Author

Thanks @pkscout

I can't speak for everyone, but my thoughts are that I wouldn't need those uncredited and one time actors in the library, so I am happy to not have them. This will also make using the actors node a little bit easier. Have you ever tried scrolling through the actors node looking for an actor? I find that entire node unusable as it is too large.

I can also see some benefit of the longer term soution, but like the MPAA redesign, it will never happen.

I am hoping that some coding to the scrapers would be easier and quicker to implement than trying to get a core developer to implement the changes.

@KarellenX
Copy link
Member Author

As an example, I rescraped my die hard movies.
Die Hard 2 has 37 actors without image URL's
Another 5 had broken links
https://www.themoviedb.org/movie/1573-die-hard-2/cast

Out of the 5 movies, I deleted over 100 actors from the nfo files

@Dogway
Copy link

Dogway commented Jan 16, 2023

Scraping 37 actors is not a problem, downloading images for the 37 of them is though, considering data management. But as you pointed most of them have no images so I think the preferred solution would be at skin or library.node level filter those without images, or 1 time appearances.

I'm personally trying to make library.nodes to limit actors to 2 or 3 appearances without success though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants