How to you handle multiple releases of the same scene?

zzz_nf · January 23, 2026, 7:55am

Some scenes are released by multiple studios, for instance re-release or when 2 performers each release a scene on their own ManyVids profile.

I’d like to have these 2 nearly-identical scenes somehow linked together (maybe in a group?). I’d also like to have the option to delete one of the two files but still keep each scene in stash, and:

have stash show the scene without the file only in specific cases (in Search and on the studio pages)
have stash show me a link or redirect me to the scene with a file when I am on the page of the scene without a file.

How do you handle these cases? Is there any plugin or pending issue on stashapp that would help with this?

kanaza · January 23, 2026, 11:52am

This has been posted to the StashDB topic, but I assume you are talking about Stash.

Stash-box might eventually introduce a Release Group concept:

github.com/stashapp/stash-box

[RFC] Release Groups / Scene Groups

opened 09:56PM - 24 Jun 23 UTC

AdultSun

help wanted

_After a brief discussion on Discord, I asked for help writing an issue addressi…ng the long requested "release groups" feature, primarily inspired by the system implemented by MusicBrainz to track multiple releases of the same album. The following is written by StashDB user 2itno. I have only made a few formatting changes to fit GitHub's flavor of Markdown._ _- AdultSun_ # SceneGroup object to group rereleases, remasters, redistributions, etc. ## Motivation It is not uncommon for studios to release a scene on different sub-sites, or to re-release a scene at a later date, possibly remastered or edited in some way. While ultimately derived from a single collection of video footage, each release or distribution of a scene may comprise a distinct set of metadata: different versions of a scene may have different titles, release dates, durations, descriptions, studio codes, studio URLs, or studio attributions. All these metadata are potential candidates for submission to StashDB. How can they be captured in the stash-box data model? Currently, there are two strategies for tracking different releases or distributions of a scene in StashDB, each with significant drawbacks. One strategy is to try to lump the different distributions into a single Scene entry. For instance, The Score Group will often release a scene simultaneously on a specific themed sub-site as well as on an aggregator site. In many cases, scenes released in this way differ only by studio URL and studio code. Editors sometimes attach both URLs to a single Scene, but a single Scene cannot capture two studio codes. In other cases, however, simultaneous or staggered releases differ in more meaningful fields like title, description, etc. A single Scene has only one title field, one details field, etc. The other strategy in use is to submit multiple Scenes. Each collection of metadata associated with a specific release event can be fully captured in this way, but there is no link between the different versions of a Scene, no way to capture in the database that the different versions are related. As a potential new solution, alternate titles have been proposed (issue #345). However, for multiple versions (redistributions, re-releases, etc.) of a scene, more than one field (e.g. date, title, studio, or description) in a Scene's metadata is likely to be different. In order to track all metadata for every release event, a Scene would then need "alternates" of many other fields. It might not be clear that alternate title # 2 is intended to correspond to alternate date # 2, and one can imagine other such UI/UX or backend issues in trying to capture multiple versions of a Scene in this manner. A saner solution is to introduce a SceneGroup object that collects multiple Scene objects, each of which represents a unique release event for a particular studio. (There could be a conceivable use for "alternate" or arrayed fields if, say, a single release event had multiple titles, covers, descriptions, etc. on a studio page. Covers are more likely to be best served by a dictionary object, but this is already out of scope of this document.) ## Tags and relationships In stash-box (stashdb) currently, if a user enters a new version of a scene as a new Scene object, the user may add one of three tags: remaster, redistribution, or re-release. As already noted these tags cannot refer to any Scene, they are just labels. These tags can remain in a Scene / SceneGroup world. One can imagine encoding relationships between scenes, for instance "`<Scene uuid#1> is a remaster of <Scene uuid#2>`". (Browse MusicBrainz to find extensive use of relationships.) In general could also be useful for describing performer actions in a scene, a Scene could have an attached relationship like "`<Performer uuid#1>` performed `<Action uuid#2>`" where Actions could be derived from a subset of current tags. Also, "`<Performer uuid#1>` performed `<Action uuid#2>` on `<Performer uuid#3>`," but this is a digression. A first implementation of a Scene / SceneGroup architecture can simply retain current tagging mechanisms for each Scene object. Asking what fields Scene and SceneGroup each should have is the next topic. ## Metadata fields What metadata should be attached to SceneGroup? Would any of a Scene's metadata subsumed into SceneGroup? MusicBrainz's ReleaseGroup contains Artist information, as various Releases may include or omit some performers (a soprano in an opera, e.g.) at the Release level, or a Release may include tracks (and thus Artists) that another Release in the same ReleaseGroup may not. Would a SceneGroup ever have a set of performers that differs from any of the grouped Scenes? Perhaps if a cameo were credited in one Scene, but not in another? No answer is provided to this question, it can be resolved by the community or developers. Similar questions can be asked regarding Tags or Images on a SceneGroup. Would SceneGroup have separately curated lists of Tags and Images? Would these be derived fields? Again, these are left as an open questions. It may be useful to choose a single canonical title for a SceneGroup. SceneGroup title performers[] tags[] images[] scenes[] Scene <all existing Scene fields> scene_group ## Specific example cases + Remasters, i.e. wherever the ["Remaster" tag](https://stashdb.org/tags/faf494d6-9092-4dd5-86d7-0978c596b547) has been used. Used frequently on NaughtyAmerica sites. For example, [https://stashdb.org/scenes/7de3d21b-f5c1-4ae3-a0aa-5c60ab78612b](https://stashdb.org/scenes/7de3d21b-f5c1-4ae3-a0aa-5c60ab78612b) is a remaster of [https://stashdb.org/scenes/5b431935-617b-4373-8ced-bdadcbb6b473](https://stashdb.org/scenes/5b431935-617b-4373-8ced-bdadcbb6b473) + Redistributions, i.e. wherever the ["Redistribution" tag](https://stashdb.org/tags/1a3906db-b644-41e3-9fe3-d0a26abb0930) has been used. Any of the "Mylf X" studios redistribute a release from another network. For example, [https://stashdb.org/scenes/9c480797-43f9-44aa-8738-08686dbf220e](https://stashdb.org/scenes/9c480797-43f9-44aa-8738-08686dbf220e) is a redistribution of [https://stashdb.org/scenes/2a9be541-7279-4894-8236-e91c36ad2474](https://stashdb.org/scenes/2a9be541-7279-4894-8236-e91c36ad2474) with different cover, date, title, etc. + Re-release, i.e. same-network scenes released on different days, possibly with updated metadata. Whenever ["Re-release" tag](https://stashdb.org/tags/8ffe05b5-9a21-4dba-a94c-c1e441790ece) is used. For example, [https://stashdb.org/scenes/0aa571d1-a677-41cd-a5ef-37cfb2c24e14](https://stashdb.org/scenes/0aa571d1-a677-41cd-a5ef-37cfb2c24e14) is a re-release of [https://stashdb.org/scenes/01a480a9-6959-4a79-98bd-b8bd44d98ba0](https://stashdb.org/scenes/01a480a9-6959-4a79-98bd-b8bd44d98ba0) + Same-network releases, or scenes listed on a parent studio and a sub-studio (see below). For example: - [https://stashdb.org/scenes/8cf99d40-9da4-44ea-9335-cfeb98e8bee1#links](https://stashdb.org/scenes/8cf99d40-9da4-44ea-9335-cfeb98e8bee1#links) has two links and is listed on both VIP 4K and Tutor 4K. - [https://stashdb.org/scenes/fef55b4b-b31c-402b-8b91-440abd81ea3a](https://stashdb.org/scenes/fef55b4b-b31c-402b-8b91-440abd81ea3a) and [https://stashdb.org/scenes/b1993722-6664-4923-9250-5ca10ba10dc0](https://stashdb.org/scenes/b1993722-6664-4923-9250-5ca10ba10dc0) are within the same network ## Edge cases Suppose a Scene title is changed. In a Scene / SceneGroup architecture, would the Scene's title get replaced? Would it get added to a list of alternates? If it were replaced, would the old title be available still, as in a versioned set of Scene objects? Would a new Scene be created in the same group? In some networks, scenes may listed both on a parent studio and a sub-studio. In some cases, a Scene may have a unique link on a parent studio and a sub-studio, but all other information is identical. For example, [this scene](https://stashdb.org/scenes/8cf99d40-9da4-44ea-9335-cfeb98e8bee1#links) has two attached links, one for the parent studio VIP 4K and another for the sub-studio Tutor 4K. All scenes in the VIP 4K network appear to be like this (though this has not been proven). This is also generally the case on [Porn Mega Load](https://www.pornmegaload.com/). Viewing the front page, you will find each scene listing to have a label like "From: <image of sub-studio>". A few test cases seem to show that the metadata on the PornMegaLoad is identical to the matching scene on the named sub-studio, but again this is not exhaustively verified. Should the parent site and the sub-studio each have their own Scene in the SceneGroup, or should there be one Scene only (assuming identical metadata) for same-network scenes with identical release dates and metadata? Probably the former is the safer and more general solution, but this can be a matter of policy to be decided by StashDB community -- the decision would probably not affect the Scene and SceneGroup object design, just guidelines for their usage. ## UI/UX changes + Stash scene search in tagger view - already can show multiple search results in stash tagger + SceneGroup view in stash and stash-box + SceneGroup edits, creating, merging, deleting, etc. + Backend changes - `findSceneGroup`, `updateSceneGroup`, etc.

In Stash, you already have the ability to create nested groups to your heart’s content. While the feature is quite powerful conceptually, it is not the most convenient to use. (You can’t create watch queues consisting of both scenes and groups, for example.)

You can also merge scenes, i.e., have multiple source files attached to the same scene metadata. In that case, only the primary file is available for playback.

To answer your question more directly, while I’m not the most knowledgeable on all of the intricacies of Stash, I think groups are your best bet. Empty scenes (without files) are possible in Stash. When you link them by adding them to the same group, the group will show up in the sidebar of the scene page. You’ll need two clicks (first to the group, then to the other scene) to reach your destination, but what you’re aiming for should be more or less possible in the current version.

I would be surprised if there were plugins that helped automate this because ultimately you have to make the decision of which file you want to keep. I imagine the duplicate checker might help in identifying re-releases.