-
-
Notifications
You must be signed in to change notification settings - Fork 804
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
[Feature] Custom scene relationships #728
Comments
It could be a little more generic also eg taged or named collections. A collection could have galleries, movies or scenes all together related. Instead of adding the movie,gallery from the scene part a new collection can be created and anything from the above added (could be even individual images in the future) including tags eg |
In essence “performer, movie, studio, tags” are all forms of typed relationships, however when used we create a named set, eg “Alison Rivers”, as the name is important. One functionality that stash is missing, is un-named but typed relationships. As an example duplicate is a type of relationship, and you may have many groups of duplicates which when specified aren’t named. eg Duplicates: [(Scene 1 & 2), (Scence 4 & 5)] Named relationships like tags are easy to create or modify, however un-named typed relationships are easy to create but hard to modify. As a scene maybe in multiple of the same type, eg a scene may appear in multiple unknownPerformer sets. One quick fix is to only allow each type of relationship to be specified for a scene once, but this seems limiting. Creation/modification is easy for automatically created sets like duplicates (eg phashing/checksum matching). However I’m curious how the UI for this would work in the unknownPerformer case. I personally think implementing un-named typed relationships isn’t worth while as for most cases humans prefer named sets, eg unknownPerfomer case: “TheBlondWithTheBig___”. Also related is the concept of tag categories, or parent/child tags. I think rather than trying to implemented un-named typed tags, it maybe better to implement tag categories (whether as a single level concept, or as part of parent/child tags). Parent/child tags can implement tag categories but this may get difficult. In the duplicate case, this means generating pseudo useless names like “duplicate_123” and “duplicate_124” but these tags live in the category duplicate. Which should have a setting, that allows this set/group/relationship to be known by the category name rather than the tags. Eg when listed in scene playback screen, it should display as “duplicate” rather than “duplicate_1231231212312”. (Additionally be hidden when manually adding)”. I prefer the the notion of tag categories with settings that determine the behaviour of that category. Difficult (from a db perspective) would be a tag setting that allows only one of a set of duplicates to be displayed in the search results. Or alternately a tag that could hide content. The tag category could also have a custom colour settings, or a setting that controls whether it displayed in the tagging edit box. Tags categories also make managing tags easier, as people use tags for many purposes, whether tagging actions/acts or personal favourite lists etc or duplicates. Tagging sources also can be handled, eg automatically tagged from metadata vs manually tagged. I also like the idea of using “:” as seperator to specific levels of tag, eg “Act:BackRub” or “UnknownPerformer:TheBlondWithTheBig___”. Just my two cents. |
Could the series have an order? Wouldn't scenes having a sorted series make movies redundant? Related to Link scenes to other related scenes or galleries, Mark scenes as not duplicate. |
I think Groups covers this use-case well enough. |
Is your feature request related to a problem? Please describe.
I have a need to relate scenes to each other for some common element. Some examples:
Describe the solution you'd like
I would like to relate multiple scenes together with a freely defined handle. So using the first example, I might relate scenes
X
,Y
andZ
together with the handleperformer
.Z
might also be related to scenesA
andB
with the handleseries
. Navigating to sceneX
would show scenesY
andZ
in a related scenes section, under the headingperformer
. Navigating to sceneZ
would also showperformer
related scenes, but would also have a sectionseries
showing scenesA
andB
.This would also allow duplicate identification to be made easier by showing related duplicate scenes.
It should be possible to query for scenes with related scenes of a given handle.
The text was updated successfully, but these errors were encountered: