Skip to content
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

[Bug Report] High CPU / looping read access when loading scene associated with removed external hard drive #5683

Open
SyZeeGee opened this issue Feb 25, 2025 · 7 comments
Labels
bug report Bug reports that are not yet verified

Comments

@SyZeeGee
Copy link

Describe the bug

When a scene's source file is on external hard drive not present (and therefore the file is not playable), the way the stash app works currently is that it repeatedly dumps out errors (The "No such file or directory" found error, until the page or video is left.)

I just confirmed the CPU usage of the browser is going through the roof when it happens so it's not ideal for that reason alone. Let me know if you'd like me to open up a dedicated issue or if its known already (I didn't know what to search)

There is one other concern in which the same happens - a file is moved and a scan operation hasn't yet registered that move. The same will happen. Meaning this could be tested with an external drive or just by moving a file and not rescanning (See reproduction below)

Originally written here (mostly the same verbiage): #5671 (comment)

To Reproduce
Steps to reproduce the behavior:

  1. Add a video file that exists on a removable drive to the stash database as a Scene.
  2. Remove the drive (or alternately move any file with OS file manager)
  3. Attempt playing the Scene that was on the removed drive (or moved)
  4. Monitor the log output of stash: "[transcode] ffmpeg error when running command </media/.../ffmpeg -hide_banner -v error -i /media/...../$$$$.mp4 -c:v copy -movflags frag_keyframe+empty_moov -ac 2 -f mp4 pipe:>: /media/..../$$$$.mp4: No such file or directory" is written dozens or more times per second - which clutters the log and induces high CPU usage.

Expected behavior

A single file access error is generated with no subsequent / looping behavior that induces read operations and high CPU.

Stash Version: (from Settings -> About): v0.27.2-66-g587fd9e6
Build hash: 587fd9e
Build time: 2025-02-24 07:00:51

Desktop (please complete the following information):
Using Linux App but this is likely universal behavior.

** Additional Context **
Not sure what happens for Images, but possibly worth checking.

@SyZeeGee SyZeeGee added the bug report Bug reports that are not yet verified label Feb 25, 2025
@github-project-automation github-project-automation bot moved this to To triage in Bug fixing Feb 25, 2025
@feederbox826
Copy link
Contributor

Are you sure the logging is causing the high CPU usage? The most likely culprit would be the attempted transcodes. When videojs has problems loading the file, it will cycle through all transcode formats until one is reached, hence the ffmpeg output

@SyZeeGee
Copy link
Author

SyZeeGee commented Feb 27, 2025

@feederbox826, I didn't presume what was causing the high CPU - it is likely a combination of anything involved in this infinite loop (I presume the file read attempts + logger)

which clutters the log and induces high CPU usage.

Ah, I see the misunderstanding - I was not associating these two statements. But another negative result of this bug is simply that the log is cluttered. So the net result is high CPU + log clutter. (Also tertiary, but markers weren't cleared when it happens)

Regards a cycling through transcode formats that is interesting. But here, this isn't the root cause imo. In that case, the function would still terminate; here it is definitely an infinite looping (no stopping condition.)

So I suppose I can clarify the above by using that terminology; "no stopping condition upon first file access failure"

It still may be a bug with internal ffmpeg and error code returned and how that is handled. I do full stack web dev, and could try diving into the code if it isn't obvious how this bug is happening, @WithoutPants and all)

@feederbox826
Copy link
Contributor

Can you pinpoint if it's the browser that is looping or stash or ffmpeg? If it's browser side then the fix would be in videojs transcoding selection, if it's stash/ffmpeg then a check for missing files and terminating the stream request would make more sense.

@SyZeeGee
Copy link
Author

SyZeeGee commented Mar 1, 2025

Based on the output to the log, the call to transcode the file is what is looping. Please let me know how I'd go about confirming what you are asking though (how to differentiate)

IMO, this means it's not the browser - or it's the result of the browser not communicating an error properly back to stash code, but I think you have more experience here as my mental model of the code / communication channels is limited currently.

@feederbox826
Copy link
Contributor

feederbox826 commented Mar 2, 2025

My browser just gives me a "partial media output" when I try to recreate it, can you share more details on how you recreated it? mostly codec and at what point the playback gets when you pull the drive out

@SyZeeGee
Copy link
Author

SyZeeGee commented Mar 2, 2025

The repro maybe wasn't clear. It doesn't require pulling drive out when playing (some amount of the file will probably be cached / loaded)

Try playing a file that was added via an external drive that isn't currently connected (when the initial file read occurs) and let me know if you get the same error as above.

@feederbox826
Copy link
Contributor

Misunderstanding on my part, I was ripping out the drive mid-playback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Bug reports that are not yet verified
Projects
Status: To triage
Development

No branches or pull requests

2 participants