stashapp / stash

An organizer for your porn, written in Go. Documentation: https://docs.stashapp.cc
https://stashapp.cc/
GNU Affero General Public License v3.0
9.23k stars 794 forks source link

[Feature] Support non-unique Studio names #5210

Open echo6ix opened 1 month ago

echo6ix commented 1 month ago

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:

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).

image

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 commented 1 month ago

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

echo6ix commented 1 month ago

@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.