Quite a percentage of the users here use the various headshot database files that others kindly share with us. Unfortunately, that can lead to rogue BY being introduced if that user has them for whatever reason.

What I suggest is having an extra option on the restore screen, something like this



When we're restoring from our own backup files we can check the box so that any BY that are needed are restored. When restoring from one of the headshot files from someone else we can uncheck it so that all that's restored are the photos.

Something I've thought of while typing this is what to do if the restore adds a new cast/crew member that shares the same name as an existing person & contains the BY in the restore file. In those situations, perhaps an extra option or auto option to flag those & ask whether or not to include the BY for those entries ONLY.

Edit: Although most don't include BY, some do so this would provide a safety net.

I would DEFINITELY support this, Forget! 

This is fine, of course, but I'd say the "bigger picture" is that Invelos really needs to re-evaluate the whole birth years principle. It's a mess:

- Unneeded birth years are regularly being accepted into the database: dozens, maybe even hundreds of "big names" for which no birth year is needed have theirs accepted into the database somehow.

- They're continually being propagated among the userbase through the sharing of headshots.

- I have to maintain dozens of fake birth years in my local database to keep people with the same names for which no birth year can be found separated from eachother. And with each one comes the risk of accidentally contributing it into the database at some point: that has already happened to me, and though the birth years were obviously fake, they were accepted without question. When I noticed, I went back and removed them, of course, but still...

- Whenever I have to restore a backup the system will merge two previously separated entries - one with a BY, one without - into a single new entry, undoing all the separation work done earlier (which warrants the need for more fake birth years).

- And the recent expansion of the crew credits means I'm stumbling upon more and more occasions where I need birth years, but can't find any (good luck in finding BY's for, say, a make-up artist). It gets even worse when you're tracking some non-contributable crew roles locally using the "custom" crew entries: depending who you track, you'll find there's a namesake for just about everyone, if you look hard enough...

All in all, the whole BY system is slowly bursting apart. This is a good suggestion to at least try and address the propagating of unneeded/unwanted birth years when importing a headshot database, but really, I think the whole system needs addressing...

Quoting Staid S Barr:

Quote:
One way out would be to actually allow birth years (if documented of course) for anybody.

I'd like to see that, too. 

I also support the idea to have BY system revisited. I often have to delete non desired BY that come back once again with profiles downloads. But, on the contrary, the system cannot avoid something to differentiate two actors with the same name. And I consider myself as lucky since I keep only directors and music composers as crew in my local...

Agree with Staid. The current BY system can't be properly audited. Many times, I go to contribute a profile and find I have a bunch of BYs not in the master. Since I don't know which profile they came in on, I can't look them up to see why they were added. A thread of accepted BYs is an ugly kludge. I support BY for all.

Ever since I started using Head shots I have never uploaded my list to others and I keep this list local.., I'm always changing the Head shots as I find a lot are either totally wrong., (some young kid with the same name as a movie start gets his pix inserted instead of the real Owner., Or I may find that a lot of  films stars from the ( i.e.) 70's are head shots of what they look like today,, ( old hair and full of BoTox)..

therefore what my interpertations are of what the picture should be is of no reflection on what others concieve the picture should be ..
therefore locked off Local only ..