Doesn't need to merge into this branch (can wait until files-refactor goes in) but this allows the pr to be reviewed now.

EDIT: No longer relevant now

Resolves #1962

I'm currently working on adding support for a hierarchy to tags where one tag could have multiple children and/or parents. This feature seems to have been requested a couple of times before, and with 0.8 adding support for tag aliases I might just as well try to add this as well and I guess tags would then have most of the desired features, or at least from management purposes.

As stated this branch is a work-in-progress, so I will list the things which I already implemented:

• [X] DB migration
• [x] Management
  • [x] Adding parent(s) / child(ren)
    • [x] Validation that no loops are created (i.e.: A => B, B => A should fail, and A => B, B => C, C => A should fail as well etc)
  • [X] Listing parent(s) / child(ren)
  • [x] Merging parents/childs when merging tags
• [X] Filters
  • [X] Scenes.Tags
  • [X] Scenes.PerformerTags
  • [x] SceneMarkers.Tags
  • [x] SceneMarkers.SceneTags
  • [X] Images.Tags
  • [X] Images.PerformerTags
  • [X] Galleries.Tags
  • [X] Galleries.PerformerTags
  • [X] Performers.Tags

For the management part (adding parent or child tags) I'm open to suggestions to how to add this to the UI. This applies to both the actual management, as listing the parents and children

This is intended as a catch-all issue to report bugs with the files-refactor alpha branch.

Known issues are as follows:

• ~~import/export functionality is currently disabled. Needs further design.~~
• missing covers are not currently regenerated. Need to consider further, especially around scene cover redesign.
• ~~deleting galleries is currently slow.~~
• ~~Don't include file extension as part of the title scan flag is not supported.~~
• ~~Set name, date, details from embedded file metadata scan flag is not supported.~~
• ~~Draft submissions to stash-box currently give an already in transaction error.~~

Other notable changes:

• Object titles are now displayed as the file basename if the title is not explicitly set. The Don't include file extension as part of the title scan flag is no longer supported.
• Set name, date, details from embedded file metadata scan flag is no longer supported. This functionality may be implemented as a built-in scraper in the future.

Please report issues with the files-refactor build here.

Fixes #495

This pull request adds caption support for DE, EN, ES, FR, IT, NL, and PT VTT files. As far as I'm aware those are the only languages that are captioned in adult content. This pull request only adds support for VTT files since video.js only supports VTT files but we could support SRT files later by converting the files to VTT on the fly, see https://github.com/videojs/video.js/issues/5923.

### Scope Rework the config page for better organization.

Long Form

As #1548 is moving scrapers to its own page, I think it would be good to take a look at the configuration section overall.

My suggestions are as follows:

Separate pages into collapsible sections, expanded by default

(like this: https://www.codehim.com/bootstrap/bootstrap-vertical-menu-with-submenu-on-click/ )

Move stuff around

(in no particular order)

Content Section

The purpose of the Library section is to show configuration settings related to WHICH CONTENT IS INDEXED OR NOT INDEXED

Library

• Video Extensions
• Image Extensions
• Gallery Zip Extensions
• Excluded Video Patterns
• Excluded Image/Gallery Patterns

Tasks

• Auto Tag (Rename "Detect Tags From Filenames")
• Scan (Rename "Add To Library...."). Also rename "Scan" and "Scan Selected" to "Scan All" and "Scan Folders..."
• Generated Content (Rename "Generate Interface Files....")

System Section

The purpose of the System section is to show configuation options and settings related to BACK-END SETTINGS

Paths Menu

• Database Path
• Generated Path
• Cache Path

Logs Menu

• Log File
• Log Level
• Current contents of "Log" page

Maintenance Menu

• Clean Database
• Backup
• Metadata Export

Indexing Section

The purpose of the System section is to show configuation options and settings related to THE INGESTION OF CONTENT

• Hashing
• Parallel Scan/Generation
• Preview Generation

Playback Section

The purpose of the Playback section is to show configuration options and settings related to VIDEO PLAYBACK

Playback Menu

• Auto-Start Video
• Maximum Loop Duration

Conversions Menu

• Transcoding options

DLNA Menu

• Existing DLNA Menu (Possible future additions: Global playback speed, video player selection, etc)

Users Section

The purpose of the Users section is to show configuration options and settings related to USER LOGIN

• (contents of Authentication section)
• Handy Connection Key

Appearance Section

The purpose of the APPEARANCE section is to show configuration options and settings related to USER INTERFACE

Interface Menu

• Language
• Menu Items (Rename "Enable/Disable sections")
• Wall Settings
• Slideshow Delay

Theme Menu

• Page showing "Currently Active Theme" with source and link to themes index on wiki (or native display of that page)

Extensions Section

Plugins Manu

The purpose of the Plugins section is to show configuration options and settings generated by PLUGINS

• "Installed Plugins", current "plugin" page but refactored as a table with Name, Description, Version, Link.
• "Refresh Plugin List" to replace "Reload Plugins" (at some point in the future, an "Add plugins" page)

Scrapers Menu

(as described in #1548 )

Tools Menu

• Existing "Tools" section

Is your feature request related to a problem? Please describe. I'd love for Stash to track the play count for scenes, so I can get a better sense of what's getting watched and what isn't.

Describe the solution you'd like I would suggest presenting the play counter next to the o_counter in the Details tab of the Scene page and on the Scene card. On the Edit tab, the functionality to decrease or reset the count would work the same as the o_counter. Instead of manually tracking this count though, Stash would automatically track every time someone plays a scene. Hit play on a scene and the count goes up.

If we wanted to get fancy, there could also be a setting for the minimum play duration required for a play to be counted, but that may be more complex than is.

Describe alternatives you've considered I think the the o_counter is the best model for the to be presented. This could also be shown as a section in the details tab, with the playcount and last play date/time show but that the o_counter style seems cleaner.

Additional context It can be hard to keep track of so many scenes, particularly when continuously adding new more. Having access to more data to use in pruning the collection is so helpful for making decisions to manage the size of the collection.

• makes all settings pages auto-save when changing options
• made settings menu fixed to the left edge of the screen and centred content panel
• restructured and reordered pages based on discussion in #1549
• change checkboxes to switches

Still to be done:

• [x] add a saving/saved indicator instead of using Toast notification
• [x] restructure and restyle Tasks page
• [x] readd some missing help links

This is a significant refactor of the transcode streaming code.

The forceMKV and forceHEVC flags have been removed, and is_streamable has been removed from the scene graphql type. Instead, there is a new IsSceneStreamable graphql query that accepts a list of supported video codecs. Similarly, the stream.mp4 route has been changed to accept a list of codecs as well. The supported video codecs are obtained using a custom Modernizr build that only tests for video support. There is an additional test for mkv support, but it is hard-coded to check if the client browser is Chromium-based.

On the backend, the transcode code is changed so that it chooses the codec to use based on the supported codecs sent to the request. It is currently hard-coded to prefer VP9, VP8, HEVC then H264. This should probably be further refined to accept the supported codecs in order of preference.

~~This doesn't fix the Safari bug referenced in #600 but is a decent first step.~~ This obsoletes a lot of the changes in #522 which will need to be reworked if we go ahead with this.

Fixes #600

The scenes table has unique indexes/constraints on path and checksum colums. The images table doesn't, which doesn't really make sense, as scanning uses these colums extensively which warrents an index, and both should be unique as well.

Adding these indexes thus heavily improves the scanning tasks performance. On a database containing 4700 images a (re)scan of those 4700 files, which thus shouldn't do anything, took 1.2 seconds, with the indexes added this only takes 0.4 seconds. Taking the same test on a generated database containing 4M images + the actual 4700 images took 26 minutes for a rescan, and with the index existing also only takes 0.4 seconds.

This is the current navbar.

This is as narrow as I can get the Window before it has to collapse to a menu button. With Audio and Text items in the roadmap, plus Playlists and such, we're going to run out of room in the navbar. We need to think about reworking it.

Some design considerations:

• we need to maintain single-click navigation for at least the most used buttons. I know that I will be bothered if I suddenly need to do two clicks to go to Scenes, Performers and Studios.
• the navitems fit into categorical groups. Scenes, Markers and Movies would fall under a Video group, and Images and Galleries would fall under an Image group, and the rest could go under Metadata.
• saved queries are in the roadmap and should ideally be accessible from the navbar.
• we should consider that on desktops, there is a lot more horizontal real estate than there is vertical
• we should ensure consistency between desktop and mobile views

Possible designs:

• on desktops, group navitems into the groups mentioned above (Metadata probably wouldn't need to grouped). The groups would be implemented as a hover dropdown button. Pornhub does something like this, as does xhamster:
• we could potentially save some horizontal realestate by increasing the height of the navbar and placing the icons above the text, with a squarer button - like how Sonarr/Radarr do it:

This would mean a loss of vertical real estate which I'm loathe to lose.

• move the items into a clickable menu like how the mobile view is currently. I'd rather not do this since it adds an extra click to all those top-level objects.
• move the items into a sidebar. Plex has this, for example:

Said sidebar is collapsible to it's icons, with the More > button only accessible when not collapsed. On most widescreens, we'd probably be losing less proportional real estate horizontally than vertically, and definitely less when collapsed. It would mean that some of our screens would need to be redesigned (the scene detail page for example).

• show only the first x items that will fit and put the rest into a More... menu button. Menu item configuration would then be order as well as inclusion.

When I generate previews and spites, I get this kind of error on some vids:

ERRO[3587] ffmpeg error when running command </usr/bin/ffmpeg -v quiet -ss 1180 -t 0.75 -i /home/user/Desktop/sort/Goga-Huxley ++.wmv -y -c:v libx264 -pix_fmt yuv420p -profile:v high -level 4.2 -preset veryslow -crf 21 -threads 4 -vf scale=640:-2 -c:a aac -b:a 128k -strict -2 /home/ziggy/stash/generated/tmp/preview010.mp4>

I ran the command manually from bash, and it does work if I add the option "-max_muxing_queue_size 400" to ffmpeg.

This pull request adds an option for tenth-place precision star ratings, as I feel the quarter and half-star options aren't precise enough to consider them over the decimal option. It's always jarring to see so many performers with a 5-star rating with quarter precision.

Describe the bug When scanning the exact new path from a graphql mutation I get the error: error processing "/path/…/file.mp4": parent folder for "/path/…/file.mp4" doesn't exist If the new file is in a subfolder Stash isn't aware of yet. A manual recursive re-scan solves this, but this has worked before this way and might be a regression introduced with the file rework some versions earlier.

To Reproduce Scan the full path of a file using metadataScan where the file is in a folder stash is currently unaware of

Expected behavior Stash scans just the file(s) in the given array regardless of parent folder and if any of the files exist in a parent folder stash is unaware of stash will document that folder and continue to scan

Stash Version: v0.18.0-25-g9351a0b2

Desktop:

• OS: Windows

Additional context originally reported in discord by @Couch#9446

I encountered this same issue using v0.18.0-25 attempting to do the same thing, could not find any discussion of this elsewhere so I've created this formal issue to track it.

Is your feature request related to a problem? Please describe. No, it's not related to a problem.

Describe the solution you'd like A feature to create smaller loops on videos would be great! There is a feature in VLC that is exactly what I mean (described here). Something quick and easy would be great. Basically so right while you're watching a video you can quickly make a loop on a specific portion of the video without having to go through the hassle, and use up the disk space, to make another separate video file of the desired clip. Something very similar to the 'Markers' functionality that is currently in Stash - but to make a little "gif" type loop of the larger video.

Describe alternatives you've considered The 'gifs' functionality on PornHub is a similar feature.

Additional context For example, if I had a video that was five minutes long and I wanted to make a loop of the video from 2:35-2:42. Perhaps it could be incorporated into the 'Markers' section - where you could have a start time and an optional end time to the marker. If there was an end time specified then the video would automatically loop during playback when watching that marker.

Add a filter for the "video codec" to easily identify videos that must be transcoded live to be played. Problem is that the live transcoding is to slow for fluid playback on some machines and it would be nice to know these scenes to re-encode them in handbrake or something.

This pull request adds an option to leave the stats page blank, making it ideal for custom charts via plugins or userscripts to run without waiting and dealing with load times that would vary based on the size of a user's stash.

Screenshot of new interface setting:

Screenshot of blank stats page:

Is your feature request related to a problem? Please describe.

I've run into the case were I would like to add files to stash via a script without kicking off plugin automations I have in place for normal scanning tasks, currently requesting a scan via the API will always kick off any enabled plugin create hooks, were I in this case I would like to just perform a scan to get the files into stash to manipulate again later without the overhead of the plugins that are not necessary.

Describe the solution you'd like

Add a flag to ScanMetadataInput that will bypass any plugin hooks for that specific scan task

Describe alternatives you've considered

Manually disabling onSceneCreate plugins when running scripts that add files via the API