[Bug Report] Captions appear to no longer be detected (on Windows)

[jonheese]

Describe the bug When scanning scenes that have caption files in place (as described in the documentation), the captions are not detected and thus are not stored in the Stash database.

To Reproduce Steps to reproduce the behavior:

1. Add SRT or VTT file to stash back-end file system, in same directory as scene video file, with same name as scene video file, but with en.srt or en.vtt suffix.
2. Scan or rescan scene.
3. No captions are detected.

I was able to pinpoint this as a bug even further by taking the following steps:

1. Find scene in Stash that already has captions detected and working.
2. Move SRT or VTT file from scene directory to temporary location.
3. Rescan scene, logs show that caption was removed from file.
4. Move SRT or VTT file back to scene directory.
5. Rescan scene.
6. No captions are detected.

This is the reason why I use the language "no longer" in the title -- this was apparently working at some point since the captions were initially detected and set properly, but is no longer working in the current release v0.20.2.

Expected behavior Entries should be logged showing that the caption file was detected and the captions enabled on the scene.

Stash Version: (from Settings -> About): Version: v0.20.2 Build hash: e685f80e Build time: 2023-04-07 22:47:42

Server:

• OS: Windows Server 2019 Standard

Desktop: (Not really applicable here, but:)

• OS: Mac Ventura 13.4
• Browser: Chrome
• Version: 113.0.5672.126 (Official Build) (x86_64)

Additional context I note that this is running on a Windows server not because I know that only Windows is affected but because I assume that most Stash installs are on Linux, so I want to call it out just in case it is important in the troubleshooting.

[jonheese]

Just wanted to note that while my Go skills are quite poor, this section strikes me as odd:

https://github.com/stashapp/stash/blob/develop/pkg/file/video/caption.go#L110-L115

Am I wrong in reading that as a switch statement with only two possible outcomes -- either break or continue, with neither case ever allowing the remaining code in the for loop to run?

[MrX292]

Did you run a full scan from the task page? It can also be if the video is not already in stash that you need to run 2 scan tasks

[jonheese]

Yes, I have run it as a full scan as well as a targeted scan to just that one scene. I have run the scan many times trying to troubleshoot this, so I'm sure it's not an issue like that reported in https://github.com/stashapp/stash/issues/2619

[DingDongSoLong4]

I can't seem to replicate this, I am on macOS though.

Just wanted to note that while my Go skills are quite poor, this section strikes me as odd:

https://github.com/stashapp/stash/blob/develop/pkg/file/video/caption.go#L110-L115

Am I wrong in reading that as a switch statement with only two possible outcomes -- either break or continue, with neither case ever allowing the remaining code in the for loop to run?

At first I thought you were on to something, but no it turns out that a break in a switch statement just exits the switch and not an outer loop. Totally not confusing or anything. https://stackoverflow.com/questions/11104085/does-a-break-statement-break-from-a-switch-select

[jonheese]

@DingDongSoLong4 Ah, okay, that explains it -- thanks.

Of course, if it were that switch statement, it would happen on your macOS system as well. Thanks for checking.

[jonheese]

I did some more testing and discovered that the "Rescan" option for a scene does not detect caption files, but the "Selective Scan" task does.

I didn't notice this initially because apparently my original subtitle file was not perfectly matched to the scene title and after I saw it wasn't being detected with a full scan, I was doing all of my testing (including fixing the SRT file name) by just using the "Rescan" option on the scene itself.

Thanks @MrX292 for your comment -- you were right after all.

So before I close this bug report -- Is it a bug that doing a Rescan on a scene doesn't detect new subtitle files?

[DingDongSoLong4]

What Rescan does is it sends a selective scan request only for that specific video file, meaning that other files aren't processed at all and thus a caption file wouldn't be scanned at all. I don't think a selective scan should scan any files other than those specified, so I don't think that it not detecting new subtitle files is a bug. At this point the system also doesn't know about the new caption files yet, so it can't include the path to the caption file in the request.

What I do think could improve is perhaps moving the Rescan option to a button in the File Info panel, and making it a bit more obvious that it will only rescan the scene video file, not scan for new files, which should hopefully help to prevent confusion like what has happened here. I might get around to doing that at some point.

[puc9]

In addition to the fact that a scene rescan does not find captions, the caption files are found before the scene while enumerating the folder if the language indicator starts with a letter < m or < w (for mp4 or webm, respectively).

So filename.en.vtt will always be found before the filename.mp4 or filename.webm.

If this is the first time scanning a folder that means the scanning didn't yet get to the video file so it did not create a scene for it. The matching code for the caption looks for a scene with the same file name, doesn't find one so it doesn't match one.

On next scan however, the scene was created already so the captions matching code is able to find the scene so it adds the caption file to the db.

I'm not sure how this behavior can be fixed without complicating the scanning code too much.

[Flashy78]

Sounds like a new feature request to keep a list of non-matched caption files during a scan, and try to match them again once the scan is finished, in order to avoid having to scan twice.

[WithoutPants]

So before I close this bug report -- Is it a bug that doing a Rescan on a scene doesn't detect new subtitle files?

It can stay open. It's a usability issue at the very least.