[Feature] Support non-unique Studio names

[echo6ix]

Problem

Limitation for unique studio names only.

Current behavior requires each studio name to be unique. While duplicate studio names is rare, more studios are publishing their content on different platforms, and they're retaining their same name on each platform. This is especially true for content creator "studios", who are often on a myriad of platforms.

This poses a problem on Stash if a user wants to organize their studios in a canonical parent-child structure for each platform, such as

- BlahVids
  - Acme Studios
- BlahHub
  - Acme Studios
- OnlyBlah
  - Acme Studios 
- BlahHamster
  - Acme Studios 

The current workaround for this is to alter the name for each non-unique studio so it meets the criteria of a unique studio name.

Requested solution

Remove the limitation of requiring unique studio names.

Possible issues

This could create a host of potential ui/ux issues, though none of the ones listed below would be unique to studio names. Mitigating these issues would require implementing some safeguards.

Duplicate studio names in drop-down select forms

Studio names would need to be differentiated in dropdown select forms. We could do this using multiple attributes. Similar to performer names in drop down select forms, the studio name could be displayed along with the following data:

• Show the parent studio name
  • Acme Studios (BlahVids)
• Show the studio url (which would be a unique identifier)
  • Acme Studios (blahvids.com/acme_studios) <-- stripping out the https://www string for brevity
• Show the studio favicon (requires adding favicon support [Feature] Upload studio favicon #2082)
  • {favicon} Acme Studios (BlahVids) or
  • {favicon} Acme Studios (Bblahvids.com/acme_studios)

Duplicate studio names in card view

Same solution as above.

Issues with autotag

Allowing non-unique studio names would increase the chance of false positives when using autotag. However, this is already a risk with duplicate performer names, and why the community generally does not promote AutoTag without cautioning the risk.

Issues with scraping

This would increase the chance of false positives when scraping when the returned studio is one of multiple non-unique studio names. Also, a liability with performers that share non-unique names.

Conceptually, there are ways to prompt the user if a returned value has multiple matches. We could use a ⚠️ icon indicator in the form field of the value that also prompts a tooltip telling the user of the duplicate name collision. Clicking the icon could open a modal window where they choose the correct name (for both duplicate studio and duplicate performer name collisions).

Clicking the icon would present a list of the duplicate names (with the disambiguation attributes mentioned above) where the user could select the precise name.

Import export and other potential backend issues

Not qualified to address these :/

[DogmaDragon]

Personally, I think it would create more issues than it would solve. Some you already mentioned. But also:

• It would complicate searching as you would need to target parent to find child studio if multiple use the same name.
• It requires additional code, which increases complexity and makes it harder to maintain. Studios touch almost every core system.
• It would also need to change studio aliases code, since they also require unique names at the moment.
• Would also complicate Stash/stash-box integration, since the latter also requires unique studio names. Though that specifically is somewhat mitigated by StashID system.

[echo6ix]

@DogmaDragon , thanks for taking the time to highlight more issues.

Many of the surface level challenges are the same that could have been posed when introducing non-unique performer names, not to imply they are insignificant or trivial. Stash is basically an app that was initially intended for very light organization of web scenes inspired by Pornganizer, and has evolved to incorporate features the base paradigm was never planned to do imo. So I can appreciate fundamental constraints it has inherited.

Yesterday WP raised similar concerns to yours's, but I wanted to formally document the FR to ensure advantages and challenges are recorded for future reference. I consider this FR intended for long-term consideration, something that should be kept on the radar.

If concepts similar to Release Groups (MusicBrainz) and Master Release-Sub Releases (Discogs) are ever implemented, I think it will significantly enhance the canonical organization of content, particularly if applied to stash-box. But a natural extension of that approach will be the desire to organize studio hierarchies in a similarly accurate and canonical structure. However, this will inevitably introduce issues with non-unique studio names.

At present it's recommended we manage this through a manual process of suffixing a disambiguating parent studio string in parentheses along with the studio name. While that workaround is feasible, it's more like a stop-gap quality measure. It's inherently inefficient and prone to human error/inconsistencies.