Files refactor bug reports

[WithoutPants]

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.

[7dJx1qP]

I got about a dozen of these errors while running my first full library scan post-migration:

level=error msg="updating files: executing `UPDATE `files` SET `basename`=?,`created_at`=?,`id`=?,`mod_time`=?,`parent_folder_id`=?,`size`=?,`updated_at`=?,`zip_file_id`=? WHERE (`files`.`id` = ?)` [[XXXXXXXXXX.avi 2022-08-04 09:36:28.7004594 -0400 -0400 672814 2022-06-30 09:30:11 -0400 -0400 8976 495341568 2022-08-04 09:36:28.7004594 -0400 -0400 <nil> 672814]]: database is locked"

And then a few of these errors:

level=error msg="error processing \"I:\\\\Sites\\\\XXXX\\\\images\\\\XXXX\\\\crop\\\\460x349\\\\nt\": creating folder \"I:\\\\Sites\\\\XXXX\\\\images\\\\XXXX\\\\crop\\\\460x349\\\\nt\": inserting into folders: executing `INSERT INTO `folders` (`created_at`, `mod_time`, `parent_folder_id`, `path`, `updated_at`, `zip_file_id`) VALUES (?, ?, ?, ?, ?, ?)` [[2022-08-04 10:47:06.7598688 -0400 EDT m=+5598.143112701 2021-05-09 14:02:00 -0400 EDT 43586 I:/Sites/XXXX/images/XXXX/crop/460x349/nt 2022-08-04 10:47:06.7598688 -0400 EDT m=+5598.143112701 <nil>]]: database is locked"

For context on my stash library size, the migration says it migrated 672809 files, db file size ~6GB, generated folder size ~200GB.

[7dJx1qP]

Had an electrical power outtage midscan, but after starting the scan again it seems like it completed fine and I didn't get any database is locked errors.

One thing I've noticed is there's a significant performance regression on the scenes page load time. My stash is about ~100k scenes and on v1.16.1 it takes less than half a second to load a page size of 20. With the files-refactor it takes between 1.5-2 seconds to load a page size of 20. The difference is much more noticable when I try a page size of 1000. On v1.16.1 it takes about 4-5 seconds while on the files-refactor it's taking around 90 seconds.

The homepage, movies, and markers pages are similarly much slower. The Images, Galleries, Performers, Studios, and Tags pages load times seem the same.

[skier233]

I found a bug with the statistics Scenes duration stat that shows your total scenes durations. It appears to be querying the scenes table and summing the duration but the scenes table no longer has a duration column.

[ferengi82]

i tried the new experimental version and get the following error at the schema migration

An error occurred migrating the database to the latest schema version. The backup database file was automatically renamed to restore the database. error performing migration: running post migrations for schema version 32: migrating files: UNIQUE constraint failed: files.parent_folder_id, files.basename

[djbtwothousandtwenty]

one of my filters for Galleries has broken. I've made different views, where i've got some paths on my nas systems that contain "favorited models" and some paths contain stuff that's fully unsorted or only sorted by studio. I filter those out with an exclude filter like:

path : excludes : \Studios\

as the path of the files is for example file://nasname/foldername/Studios/studioname/performername/somefile.zip I did try /Studios/ as well, no difference. This worked on 0.16.1. I'm running this on Windows with the shares on the NAS mounted via SMB. The same filter still works for Scenes I just noticed.

For scenes a similar filter I use, again on Path:

path: includes: ".and." combined with a filter on performer count (1 or less) to find some scenes where only 1 of multiple performers has been tagged, so i can then go and find the other performers and manually add them to the scene and improve the metadata. This one also does not work anymore.

[djbtwothousandtwenty]

There's a bug in the Settings on the Tasks tab. On setting any of the settings for Library Scan, and hitting the Scan button, all settings for Library Scan get disabled.

[djbtwothousandtwenty]

Scan settings issue has been fixed for me with #https://github.com/stashapp/stash/pull/2811

[ferengi82]

with the new version I got this error:

An error occurred migrating the database to the latest schema version. The backup database file was automatically renamed to restore the database. error performing migration: running post migrations for schema version 32: migrating files: migrating file /storage/xxx/000-studio/2000-11-07 - Adriana Sage Jon Dough in Bring'um Young 1 - Adrianna Sage Adriana Sage.m4v: UNIQUE constraint failed: files.parent_folder_id, files.basename

next, I reinstalled the last stable, renamed the file (removed the ' in bring'um), clean and full rescan.

then back to experimental, now the migration worked.

[djbtwothousandtwenty]

I got about a dozen of these errors while running my first full library scan post-migration:

level=error msg="updating files: executing `UPDATE `files` SET `basename`=?,`created_at`=?,`id`=?,`mod_time`=?,`parent_folder_id`=?,`size`=?,`updated_at`=?,`zip_file_id`=? WHERE (`files`.`id` = ?)` [[XXXXXXXXXX.avi 2022-08-04 09:36:28.7004594 -0400 -0400 672814 2022-06-30 09:30:11 -0400 -0400 8976 495341568 2022-08-04 09:36:28.7004594 -0400 -0400 <nil> 672814]]: database is locked"

And then a few of these errors:

level=error msg="error processing \"I:\\\\Sites\\\\XXXX\\\\images\\\\XXXX\\\\crop\\\\460x349\\\\nt\": creating folder \"I:\\\\Sites\\\\XXXX\\\\images\\\\XXXX\\\\crop\\\\460x349\\\\nt\": inserting into folders: executing `INSERT INTO `folders` (`created_at`, `mod_time`, `parent_folder_id`, `path`, `updated_at`, `zip_file_id`) VALUES (?, ?, ?, ?, ?, ?)` [[2022-08-04 10:47:06.7598688 -0400 EDT m=+5598.143112701 2021-05-09 14:02:00 -0400 EDT 43586 I:/Sites/XXXX/images/XXXX/crop/460x349/nt 2022-08-04 10:47:06.7598688 -0400 EDT m=+5598.143112701 <nil>]]: database is locked"

For context on my stash library size, the migration says it migrated 672809 files, db file size ~6GB, generated folder size ~200GB.

i've got a few of these database locked errors as well during the first scan after db migration:

time="2022-08-08 18:34:01" level=error msg="updating files: executing UPDATE files SET basename=?,created_at=?,id=?,mod_time=?,parent_folder_id=?,size=?,updated_at=?,zip_file_id=? WHERE (files.id = ?) [[videoname.4k.mp4 2022-08-08 18:30:41.7705847 +0200 +0200 7095946 2022-08-08 08:19:25 +0200 +0200 91365 1892803057 2022-08-08 18:30:41.7705847 +0200 +0200 <nil> 7095946]]: database is locked"

[7dJx1qP]

Tried the latest file-refactor release and still getting slow performance. Using the network tab to measure times now, on v1.16.1 with 1000 page size and random sort order I get graphql requests taking ~3s. On the files-refactor it's ~1.2min.

I looked through the logs with log level trace and it looks like the total logged SQL query time is neglible compared to the overall time taken and the slow performance is coming from something else.

[djbtwothousandtwenty]

i see the same issue here. on 0.1.16 im able to rescan my full library (17 tb total spread over 2 nas devices on smb in windows) within 8 hours, on the refactor version it's been going for over 2 days and is about 20% in. I don't want to complain about performance, but there's definitely a performance regression somewhere. I've tried to find if there were any slow queries being logged, but most, if not all db calls that end up being traced seem to be around 513.1µs. Im not sure the issue is in the DB side of things, or the query limiting performance is not being traced.

I've experimented with the thread count in settings, going between 0 and increments of 2 up to 20 to see if that makes a difference, my cpu is a 12 core (24 with hyperthreading), but that hardly seems to make a difference. in the 0.16.1 version i've had it set to 9 threads.

An observation is that only during scanning/thumbprinting of large videofiles, does the network adapter ever get fully taxed up to the 1gbit maximum, where with 0.16.1 that'd be happening regardless of whether it was processing video files or images. Processing just galleries consisting of jpg files (no zips) on 0.16.1 would get network speeds between 700mbit and 1000mbit on my environment. So far the initial scan has not reached the gallery zip files yet, so i still need to see if those speed up the process.

[djbtwothousandtwenty]

a Clean, empty db makes a world of difference. Comparing 0.16.0 to filesrefactor as below, with the same dataset (109gb of mixed video both sd, 1080p and 4k and image content without zips consisting of 23.713 files and 378 folders.) on the same hardware and with the exact same configuration:

version	clean/existing	First scan	Second scan	first scan difference	second scan difference
v0.16.1-1-gcba0fddf	clean	0:29:07	0:00:09
v0.16.1-1-gcba0fddf	existing	0:30:32	0:00:11	0:01:25	0:00:02
files-refactor-release-1-g27007365	clean	0:59:33	0:00:40	0:30:26	0:00:31
files-refactor-release-1-g27007365	existing	1:21:56	1:30:10	0:52:49	1:30:01

Edited: 4 runs over same content in 2 configurations (deleted db and with the existing "production db from 0.16.1).

[skier233]

I'm experiencing an issue where when I try to delete scenes, the source files are not deleted.

[MrX292]

some scene sort options do not work like File Size, Interactive and Interactive speed. i get for File Size: error finding IDs: running query: SELECT DISTINCT scenes.id FROM scenes ORDER BY cast(scenes.size as integer) DESC LIMIT 40 OFFSET 0 [[]]: error executing `SELECT DISTINCT scenes.id FROM scenes ORDER BY cast(scenes.size as integer) DESC LIMIT 40 OFFSET 0 ` [[]]: no such column: scenes.size Interactive: error finding IDs: running query: SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive DESC LIMIT 40 OFFSET 0 [[]]: error executing `SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive DESC LIMIT 40 OFFSET 0 ` [[]]: no such column: scenes.interactive Interactive speed: error finding IDs: running query: SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive_speed DESC LIMIT 40 OFFSET 0 [[]]: error executing `SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive_speed DESC LIMIT 40 OFFSET 0 ` [[]]: no such column: scenes.interactive_speed

[djbtwothousandtwenty]

a Clean, empty db makes a world of difference. Comparing 0.16.0 to filesrefactor as below, with the same dataset (109gb of mixed video both sd, 1080p and 4k and image content without zips consisting of 23.713 files and 378 folders.) on the same hardware and with the exact same configuration:

version clean/existing First scan Second scan first scan difference second scan difference v0.16.1-1-gcba0fddf clean 0:29:07 0:00:09     v0.16.1-1-gcba0fddf existing 0:30:32 0:00:11 0:01:25 0:00:02 files-refactor-release-1-g27007365 clean 0:59:33 0:00:40 0:30:26 0:00:31 files-refactor-release-1-g27007365 existing 1:21:56 1:30:10 0:52:49 1:30:01 Edited: 4 runs over same content in 2 configurations (deleted db and with the existing "production db from 0.16.1).

think i might have solved this issue, ran an ANALYZE and PRAGMA OPTIMIZE command on my sqlite db while it was slowly chugging along, right after that the speed increased exponentially, back to 0.16.1 speeds (at least visually in the UI). Will leave it running and then see what's different in the db compared to the non analyzed / optimized versions.

[djbtwothousandtwenty]

I'm experiencing an issue where when I try to delete scenes, the source files are not deleted.

i can not reproduce this on my environment, deleting scenes works fine for me. It seems to create a whateverthefilenamewas.mp4.delete file which i then find in my recycle bin on the nas.

[djbtwothousandtwenty]

some scene sort options do not work like File Size, Interactive and Interactive speed. i get for File Size: error finding IDs: running query: SELECT DISTINCT scenes.id FROM scenes ORDER BY cast(scenes.size as integer) DESC LIMIT 40 OFFSET 0 [[]]: error executing `SELECT DISTINCT scenes.id FROM scenes ORDER BY cast(scenes.size as integer) DESC LIMIT 40 OFFSET 0 ` [[]]: no such column: scenes.size Interactive: error finding IDs: running query: SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive DESC LIMIT 40 OFFSET 0 [[]]: error executing `SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive DESC LIMIT 40 OFFSET 0 ` [[]]: no such column: scenes.interactive Interactive speed: error finding IDs: running query: SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive_speed DESC LIMIT 40 OFFSET 0 [[]]: error executing `SELECT DISTINCT scenes.id FROM scenes ORDER BY scenes.interactive_speed DESC LIMIT 40 OFFSET 0 ` [[]]: no such column: scenes.interactive_speed

confirmed on my environment

[djbtwothousandtwenty]

̶i̶̶̶'̶̶̶m̶̶̶ ̶̶̶m̶̶̶i̶̶̶s̶̶̶s̶̶̶i̶̶̶n̶̶̶g̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶"̶̶̶D̶̶̶u̶̶̶p̶̶̶l̶̶̶i̶̶̶c̶̶̶a̶̶̶t̶̶̶e̶̶̶d̶̶̶ ̶̶̶(̶̶̶p̶̶̶h̶̶̶a̶̶̶s̶̶̶h̶̶̶)̶̶̶"̶̶̶ ̶̶̶f̶̶̶i̶̶̶l̶̶̶t̶̶̶e̶̶̶r̶̶̶ ̶̶̶o̶̶̶p̶̶̶t̶̶̶i̶̶̶o̶̶̶n̶̶̶ ̶̶̶o̶̶̶n̶̶̶ ̶̶̶I̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶s̶̶̶.̶̶̶ ̶̶̶C̶̶̶o̶̶̶u̶̶̶l̶̶̶d̶̶̶ ̶̶̶b̶̶̶e̶̶̶ ̶̶̶s̶̶̶i̶̶̶n̶̶̶c̶̶̶e̶̶̶ ̶̶̶a̶̶̶l̶̶̶l̶̶̶ ̶̶̶i̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶s̶̶̶ ̶̶̶d̶̶̶o̶̶̶ ̶̶̶a̶̶̶p̶̶̶p̶̶̶e̶̶̶a̶̶̶r̶̶̶ ̶̶̶t̶̶̶o̶̶̶ ̶̶̶h̶̶̶a̶̶̶v̶̶̶e̶̶̶ ̶̶̶a̶̶̶ ̶̶̶f̶̶̶i̶̶̶n̶̶̶g̶̶̶e̶̶̶r̶̶̶p̶̶̶r̶̶̶i̶̶̶n̶̶̶t̶̶̶ ̶̶̶(̶̶̶M̶̶̶d̶̶̶5̶̶̶ ̶̶̶b̶̶̶a̶̶̶s̶̶̶e̶̶̶d̶̶̶)̶̶̶ ̶̶̶w̶̶̶h̶̶̶i̶̶̶c̶̶̶h̶̶̶ ̶̶̶i̶̶̶s̶̶̶ ̶̶̶n̶̶̶o̶̶̶t̶̶̶ ̶̶̶p̶̶̶h̶̶̶a̶̶̶s̶̶̶h̶̶̶.̶̶̶ ̶̶̶N̶̶̶o̶̶̶t̶̶̶ ̶̶̶s̶̶̶u̶̶̶r̶̶̶e̶̶̶ ̶̶̶i̶̶̶f̶̶̶ ̶̶̶p̶̶̶h̶̶̶a̶̶̶s̶̶̶h̶̶̶ ̶̶̶i̶̶̶s̶̶̶ ̶̶̶i̶̶̶n̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶c̶̶̶a̶̶̶r̶̶̶d̶̶̶s̶̶̶ ̶̶̶f̶̶̶o̶̶̶r̶̶̶ ̶̶̶i̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶s̶̶̶ ̶̶̶a̶̶̶n̶̶̶d̶̶̶ ̶̶̶g̶̶̶a̶̶̶l̶̶̶l̶̶̶e̶̶̶r̶̶̶i̶̶̶e̶̶̶s̶̶̶.̶̶̶ ̶̶̶W̶̶̶i̶̶̶t̶̶̶h̶̶̶ ̶̶̶g̶̶̶a̶̶̶l̶̶̶l̶̶̶e̶̶̶r̶̶̶i̶̶̶e̶̶̶s̶̶̶ ̶̶̶i̶̶̶t̶̶̶ ̶̶̶c̶̶̶o̶̶̶u̶̶̶l̶̶̶d̶̶̶ ̶̶̶b̶̶̶e̶̶̶ ̶̶̶i̶̶̶n̶̶̶t̶̶̶e̶̶̶r̶̶̶e̶̶̶s̶̶̶t̶̶̶i̶̶̶n̶̶̶g̶̶̶ ̶̶̶t̶̶̶o̶̶̶ ̶̶̶f̶̶̶i̶̶̶r̶̶̶s̶̶̶t̶̶̶ ̶̶̶g̶̶̶e̶̶̶n̶̶̶e̶̶̶r̶̶̶a̶̶̶t̶̶̶e̶̶̶ ̶̶̶a̶̶̶ ̶̶̶o̶̶̶n̶̶̶e̶̶̶ ̶̶̶i̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶ ̶̶̶m̶̶̶o̶̶̶s̶̶̶a̶̶̶i̶̶̶c̶̶̶ ̶̶̶o̶̶̶f̶̶̶ ̶̶̶a̶̶̶l̶̶̶l̶̶̶ ̶̶̶i̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶s̶̶̶ ̶̶̶i̶̶̶n̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶g̶̶̶a̶̶̶l̶̶̶l̶̶̶e̶̶̶r̶̶̶y̶̶̶ ̶̶̶s̶̶̶o̶̶̶ ̶̶̶y̶̶̶o̶̶̶u̶̶̶ ̶̶̶e̶̶̶n̶̶̶d̶̶̶ ̶̶̶u̶̶̶p̶̶̶ ̶̶̶w̶̶̶i̶̶̶t̶̶̶h̶̶̶ ̶̶̶a̶̶̶ ̶̶̶s̶̶̶i̶̶̶m̶̶̶i̶̶̶l̶̶̶a̶̶̶r̶̶̶ ̶̶̶o̶̶̶b̶̶̶j̶̶̶e̶̶̶c̶̶̶t̶̶̶ ̶̶̶a̶̶̶s̶̶̶ ̶̶̶w̶̶̶i̶̶̶t̶̶̶h̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶s̶̶̶c̶̶̶e̶̶̶n̶̶̶e̶̶̶s̶̶̶,̶̶̶ ̶̶̶a̶̶̶n̶̶̶d̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶n̶̶̶ ̶̶̶r̶̶̶u̶̶̶n̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶p̶̶̶h̶̶̶a̶̶̶s̶̶̶h̶̶̶ ̶̶̶l̶̶̶o̶̶̶g̶̶̶i̶̶̶c̶̶̶ ̶̶̶o̶̶̶v̶̶̶e̶̶̶r̶̶̶ ̶̶̶i̶̶̶t̶̶̶ ̶̶̶t̶̶̶o̶̶̶ ̶̶̶i̶̶̶d̶̶̶e̶̶̶n̶̶̶t̶̶̶i̶̶̶f̶̶̶y̶̶̶ ̶̶̶s̶̶̶i̶̶̶m̶̶̶i̶̶̶l̶̶̶a̶̶̶r̶̶̶/̶̶̶v̶̶̶e̶̶̶r̶̶̶y̶̶̶ ̶̶̶s̶̶̶i̶̶̶m̶̶̶i̶̶̶l̶̶̶a̶̶̶r̶̶̶/̶̶̶e̶̶̶x̶̶̶a̶̶̶c̶̶̶t̶̶̶l̶̶̶y̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶s̶̶̶a̶̶̶m̶̶̶e̶̶̶ ̶̶̶g̶̶̶a̶̶̶l̶̶̶l̶̶̶e̶̶̶r̶̶̶i̶̶̶e̶̶̶s̶̶̶ ̶̶̶b̶̶̶a̶̶̶s̶̶̶e̶̶̶d̶̶̶ ̶̶̶o̶̶̶n̶̶̶ ̶̶̶c̶̶̶o̶̶̶n̶̶̶t̶̶̶e̶̶̶n̶̶̶t̶̶̶.̶̶̶ ̶̶̶g̶̶̶u̶̶̶e̶̶̶s̶̶̶s̶̶̶ ̶̶̶t̶̶̶h̶̶̶a̶̶̶t̶̶̶ ̶̶̶w̶̶̶o̶̶̶u̶̶̶l̶̶̶d̶̶̶ ̶̶̶o̶̶̶n̶̶̶l̶̶̶y̶̶̶ ̶̶̶w̶̶̶o̶̶̶r̶̶̶k̶̶̶ ̶̶̶o̶̶̶n̶̶̶ ̶̶̶g̶̶̶a̶̶̶l̶̶̶l̶̶̶e̶̶̶r̶̶̶i̶̶̶e̶̶̶s̶̶̶ ̶̶̶t̶̶̶h̶̶̶a̶̶̶t̶̶̶ ̶̶̶h̶̶̶a̶̶̶v̶̶̶e̶̶̶ ̶̶̶t̶̶̶h̶̶̶e̶̶̶ ̶̶̶s̶̶̶a̶̶̶m̶̶̶e̶̶̶ ̶̶̶i̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶ ̶̶̶c̶̶̶o̶̶̶u̶̶̶n̶̶̶t̶̶̶ ̶̶̶a̶̶̶n̶̶̶d̶̶̶ ̶̶̶o̶̶̶r̶̶̶d̶̶̶e̶̶̶r̶̶̶,̶̶̶ ̶̶̶b̶̶̶u̶̶̶t̶̶̶ ̶̶̶i̶̶̶t̶̶̶'̶̶̶d̶̶̶ ̶̶̶b̶̶̶e̶̶̶ ̶̶̶a̶̶̶ ̶̶̶g̶̶̶o̶̶̶o̶̶̶d̶̶̶ ̶̶̶s̶̶̶t̶̶̶a̶̶̶r̶̶̶t̶̶̶?̶̶̶ ̶̶̶ ̶̶̶ ̶a̶̶̶n̶̶̶y̶̶̶w̶̶̶a̶̶̶y̶̶̶,̶̶̶ ̶̶̶w̶̶̶h̶̶̶a̶̶̶t̶̶̶ ̶̶̶i̶̶̶ ̶̶̶g̶̶̶u̶̶̶e̶̶̶s̶̶̶s̶̶̶ ̶̶̶i̶̶̶'̶̶̶m̶̶̶ ̶̶̶s̶̶̶a̶̶̶y̶̶̶i̶̶̶n̶̶̶g̶̶̶ ̶̶̶i̶̶̶s̶̶̶:̶̶̶ ̶̶̶i̶̶̶'̶̶̶m̶̶̶ ̶̶̶m̶̶̶i̶̶̶s̶̶̶s̶̶̶i̶̶̶n̶̶̶g̶̶̶ ̶̶̶a̶̶̶ ̶̶̶f̶̶̶i̶̶̶l̶̶̶t̶̶̶e̶̶̶r̶̶̶ ̶̶̶t̶̶̶o̶̶̶ ̶̶̶f̶̶̶i̶̶̶g̶̶̶u̶̶̶r̶̶̶e̶̶̶ ̶̶̶o̶̶̶u̶̶̶t̶̶̶ ̶̶̶w̶̶̶h̶̶̶i̶̶̶c̶̶̶h̶̶̶ ̶̶̶d̶̶̶u̶̶̶p̶̶̶l̶̶̶i̶̶̶c̶̶̶a̶̶̶t̶̶̶e̶̶̶ ̶̶̶i̶̶̶m̶̶̶a̶̶̶g̶̶̶e̶̶̶s̶̶̶ ̶̶̶i̶̶̶ ̶̶̶h̶̶̶a̶̶̶v̶̶̶e̶̶̶.̶̶̶

edit: found it, you can do this with filter "file count" larger than 1

[skier233]

I'm experiencing an issue where when I try to delete scenes, the source files are not deleted.

i can not reproduce this on my environment, deleting scenes works fine for me. It seems to create a whateverthefilenamewas.mp4.delete file which i then find in my recycle bin on the nas.

Hmm. On my system the file I was trying to delete is on a different drive than where stash is running from. Maybe this could be a factor?

[7dJx1qP]

I'm experiencing an issue where when I try to delete scenes, the source files are not deleted.

i can not reproduce this on my environment, deleting scenes works fine for me. It seems to create a whateverthefilenamewas.mp4.delete file which i then find in my recycle bin on the nas.

Hmm. On my system the file I was trying to delete is on a different drive than where stash is running from. Maybe this could be a factor?

Is the "Delete file (and funscript)" option selected when you delete?

[skier233]

Yea. And I tried it a few times and it seems to always have the same behavior.

[djbtwothousandtwenty]

small bug, the folder crawler finds folders which have an image that is within the excluded filenames list, but still adds a folder for it:

Performerfoldername doesn't exist. Creating new folder entry...

it should probably check whether the content that triggered the folder crawler to find the folder, was only a file that's not wanted in the db

[djbtwothousandtwenty]

on re-scanning zip galleries i mainly get these:

error processing "\\nas\galleryfolder\galleryfilename.zip": adding file to gallery: inserting into galleries_files: executing INSERT INTO galleries_files (gallery_id, primary, file_id) VALUES (114849, 0, 7072240) [[]]: UNIQUE constraint failed: galleries_files.gallery_id, galleries_files.file_id

[djbtwothousandtwenty]

on the performer page > Galleries view, sorting by Path (ascending or descending) does not change the sort order anymore. This is also the case on the Galleries page (/galleries?sortby=path&sortdir=desc)

[djbtwothousandtwenty]

Using the clean task, on deleted scenes (deleted outside of stash)

2022-08-16 23:01:09 Error
Error deleting folder "\\nas\folder\filename.1080p.MP4" from database: destroying folders: executing DELETE FROM folders WHERE (folders.id IN (92216)) [[]]: FOREIGN KEY constraint failed

this also occurs on zip files that no longer exist.

[djbtwothousandtwenty]

Scan settings issue has been fixed for me with ##2811

i've found one more location where this still happens: if I set the generate options for Scan task all to ON, but do not hit the scan buttons, it seems to save the setting correctly. it resets those specific sliders to the OFF position immediately after hitting the Generate button though

[djbtwothousandtwenty]

the autotagger seems to increasingly take longer time over each set of 1000 items it processes:

SLOW SQL [302.7667ms]: SELECT DISTINCT images.id FROM images LEFT JOIN images_files ON images_files.image_id = images.id LEFT JOIN files ON images_files.file_id = files.id LEFT JOIN folders ON files.parent_folder_id = folders.id WHERE (((folders.path LIKE ? AND files.basename LIKE ?) OR (folders.path LIKE ?)) AND (images.organized = 0)) LIMIT 1000 OFFSET 594000 , args: [//nas/foldername % //nas/foldername/%]

^ that's after about 600000 images

[djbtwothousandtwenty]

Galleries no longer get tagged for me, no errors in the logs. Images inside the galleries do get tagged correctly, but not the folder based gallery. Manual scrape with Autotag does give the correct tags, so there's a manual workaround :)

[ferengi82]

the renamerOnUpdate doesn't work with this release, maybe there are other plugins that are affected. https://github.com/stashapp/CommunityScripts/issues/73

[ferengi82]

when you try to submit a new performer to stash-box I got an error

Submission failed
already in transaction