[Feature] Studio based performer structure needed!

[T-prog3]

Is your feature request related to a problem? Please describe.
So i have this annoying problem where i for example have 23 different performers called Emily and the software only allow unique names.
In other words it seems to take for granted that all performers names in the world are unique and have a structure of FirstName + LastName. As of now the only solution is to create Emily 1 2 3 4 5 6.... But this clash with studios who already have this approach and Emily 2 in a certain studios have to be Emily 2-1 2-2 2-3....

Describe the solution you'd like
I would like there to be a separation between Performers and what i would call StudioPerformers.
The main problem could be solvable if you where able to add StudioPerformers to the studio after you created one and have the name be unique in relation to that studio and not global like it is right now. This would allow us to organize all studios/sites and not just those that have a certain pattern.

In the Performers page i also request a option to also show StudioPerformers where these would show only if there is no connection to a StandardPerformer.

StudioPerformers could also be a bridge to show performers aliases on different studios in their profile.

[ALonelyJuicebox]

IMO...the easier solution here would be to just remove the unique constraint of the name.

This would remove the need to fuss about with the database schema.
There are occassions where you might have multiple performer names that aren't associated to a particular studio, which would further complicate the studioperformer approach you're defining here.

In either event though, a problem that would arise as a result of removing the unique constraint is a much more complicated UX when selecting the performer on the Edit tab.

Is the "right" Emily the first Emily in the list? The fourth Emily? You have no ability to determine this just by scrolling down through the list. This would ideally require some GUI modifications to maybe display the performer image while scrolling through the list.

Edit: Grammar

[T-prog3]

Update:

1. It's an easier approach yes but as you say it creates other issues. Just removing the unique constraint would make it even harder to organize sites and performers. You wouldn't know if you already created a performer or not, especially if you have a large amount of performers. I also think auto tag would break so it's not a good alternative in my opinion.

2. I really think we have two problems here. One that arises due to sites/studios being so different and yet we treat them all as one which create conflicting names. The second is how you handle performers without a studio and if their name already exists.

3. I argue that the first problem would be solved by adding Studio Performers as something separated from the default performer. A Studio Performer would be something like a outline of a Performer, but because it is not created in the default way its just a shell that only exist in the studio/site. My thought behind this is that the studio/site sets the structure that we have to work with to organize our content. So we really need to start with the Studio/site to be able to organize. And to do that we first have to replicate their structure so that we can shape it into what we would like. And because each site and studio is different it seems natural to me that we create this structure at the page of each studio without having to deal with the whole database at every new input.

Studio Performers in my mind is a unique value that exists only in relation to that site/studio which makes it possible to have as many Emily's as you want because they would be represented as theStudio.com -> Emily. Emily at this point is just an alias that is not connected to a Stash Performer. theStudio.com -> Emily exists only at the studio page as a model and is a reference to her content there nothing more.

You would then be able to make a connection between theStudio.com -> Emily and a Stash Performer. Lets say she do have an official name that is Kate Rose. The connection would be theStudio.com -> Emily === Kate Rose In Kate Rose Stash Performer profile we would now be able to see a reference that shows her alias as Emily at theStudio.com.

---

But what about if Emily doesn't have a official name and we only know her as Emily?
Because of her representation as the alias theStudio.com -> Emily we still be able to show her in the Stash Performer list with all other performers if we add the include option to show Studio Performers as their alias if not connected to a Stash Performer.

What about if her name is Emily at one studio and Amy at another?
The ability to make a connection between alias and Stash Performer could be extended to include a connection between one alias and another and make the user choose what name to present in the Stash Performer list.

What about we have two different Kate Rose we want to create in our Stash Performers?
One or both could be saved with the unique key as theStudio.com -> Kate Rose and both be shown as Kate Rose

What about if she doesn't have a studio?
If a performer doesn't have a studio then create a fake studio (Independent). Every performer should be unique in relation to some well defined context. The more specificity the better.

---

With this approach you do not have to worry about compatibility issues with every other site/studio you have cause what you created is in relation to that site only. I mean just take a look at a database like https://www.indexxx.com/m?l=a almost every single girl go by a lot of different names. You then realize that as of now it's impossible to create a structure that doesn't conflict. More specificity is really needed and i believe that a site/studio based structure with Studio Performers is the only way.

[stg-annon]

Your StudioPerformers Idea has been mentioned previously (#422) where it would be tied to a performer alias, as for performers themselves I think Stash-Box has a nice solution to this, disambiguation fields, either automatic or manual.

[T-prog3]

It have similarities to what you mention but its not the same idea. The structure of that solution is a Performer based structure where you then add alias to a Stash Performer.

I talk about a Site/studio based structure. The difference is the amount of data you work with, hence less issues with performers that only go by one name. You achieve this because it's separated from the Stash Performer until you do a connection.

To clarify the difference:
If you organize a collection through a performer based structure you always start with the Performer without thinking about the context. This makes it hard when scaling because you work with all Performers at every action you do. And the more you add the harder it becomes to remember who you already added or not.

In a sites/studios based structure you work with that site only. Less performers to worry about and you get a clear understanding about what you already done. No comparability issues between sites/studios. This is why you should separate what i call Studio Performer aka alias from our Stash Performer

• If you Auto Tag a performer based structure you look for that name over the full database content and get false-positives.

• If you Auto Tag a sites/studios based structure you look for names only in that site.

• performer based structure have more error because it goes from the from specified to general when it uses Performers name as the unique value and then go to the site.

• sites/studios based structure have less errors because it goes from the general to specified.

[FormBurden]

@T-prog3 Essentially what you have put for ideas is exactly what I'm looking for. I recently got Stash and it's amazing, so now doing the long categorizing... from nearly a decade of content. And while I do enjoy the performers 'tab' and how you can generalize the performer based off of TheNude or Indexxx or whatever, having a profile for the same model on a specific site would be nice.

Since my collection is large, I've tried to even categorize based off of folder structure (before I found an app like this), and have synmlinks to folders that would be the Pictures or Videos of the models, and/or fetishes/niches/tags. And specific site related, which is what I like most of the time when organizing.

Pretty much what you stated with site specific, some of the structure is there. Such as when you use a scraper that supports the gallery/scene as well as the model, when you do the gallery/scene/performer way, you can link the person to a profile that is also from that specific site. But then it gets messy because while you can view models from a specific site already, it's still connected to "Stash Performer", even if you didn't get the models info from an actual database (TheNude, Indexxx, etc.).

Therefore something like you stated, where the model from that site, you can build a specific profile, then possibly linking it to the actual Stash Database Performers' page.

Hope to see something like this in the near future. Because having a main Stash Performer profile, and clicking on the performer, and you can click on their specific site, that also has a built profile for that site; would be a fantastic feature!!