You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Skip unreadable files instead of hanging the scan (#70) (v2.7.1)
A file whose raw reads stall (dead NFS/SMB/fuse mount, failing disk
sector) blocked a chunk worker in the kernel forever: os.stat, libmagic
type detection, and the SHA-256 hash read ran with no deadline, before
any of the timeout-guarded external tools. Progress froze with no
ffmpeg/ImageMagick process visible, and because the file stayed
'pending', a container restart resumed straight back into the same hang.
- stat/magic/hash now run under a watchdog-thread deadline
(FILE_READ_TIMEOUT_SECS, default 60s; hash deadline scales with file
size assuming a 5MB/s storage floor)
- on timeout the file is marked corrupted with a stalled-read detail and
persisted, so no scan path re-selects it
- at 32 concurrently stalled reads, new reads fail fast so a dead mount
degrades to per-file errors instead of fd exhaustion
- scan_file error results are now persisted in the non-chunked paths too
- FILE_READ_TIMEOUT_SECS and FFPROBE_TIMEOUT_SECS documented in
docs/CONFIGURATION.md
Copy file name to clipboardExpand all lines: CHANGELOG.MD
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,12 @@ All notable changes to this project will be documented in this file.
5
5
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
6
6
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0).
7
7
8
+
## [2.7.1] - 2026-07-16
9
+
10
+
### Fixed
11
+
12
+
- **A single unreadable file no longer hangs an entire scan (#70).** External tools (ffprobe, ffmpeg, ImageMagick) already run under hard timeouts, but the pure-Python reads that precede them - os.stat, libmagic type detection, and the SHA-256 hash read - had none. A file on stalled storage (dead NFS/SMB/fuse mount, failing disk sector) blocked the chunk worker in the kernel forever with no ffmpeg or ImageMagick process visible, the progress counter and ETA froze, and because the file was still `pending`, restarting the containers resumed the scan straight back into the same hang. These reads now run under a watchdog deadline (`FILE_READ_TIMEOUT_SECS`, default 60s; the hash deadline additionally scales with file size at an assumed 5MB/s floor). On timeout the file is marked corrupted with a "stalled read" detail, the result is persisted so no scan path re-selects the file, and the scan moves on. A stalled read that times out abandons one watchdog thread until the kernel releases it; at 32 concurrently stalled reads new reads fail fast instead of piling up, so a fully dead mount degrades to fast per-file errors rather than fd exhaustion.
Copy file name to clipboardExpand all lines: docs/CONFIGURATION.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -62,6 +62,8 @@ All configuration is done via environment variables, either in `.env` file or di
62
62
|`MAX_OUTPUT_SIZE`|`10000`| Max output characters before rotation | 10000-50000 |
63
63
|`OUTPUT_ROTATION_ENABLED`|`true`| Enable output truncation |`true` for large scans |
64
64
|`FREEZE_DETECTION_ENABLED`|`true`| Enable video freeze detection (freezedetect + blackdetect) |`false` to skip and reduce scan time |
65
+
|`FILE_READ_TIMEOUT_SECS`|`60`| Deadline in seconds for raw file reads (stat, type detection, hash). A file whose reads stall past it (dead network mount, failing sector) is marked corrupted and skipped instead of hanging the scan. The hash deadline scales up with file size assuming at least 5MB/s storage throughput | Raise the base on storage slower than 5MB/s sustained |
66
+
|`FFPROBE_TIMEOUT_SECS`|`120`| Hard ceiling in seconds for ffprobe metadata reads | Raise on very slow storage |
65
67
66
68
**Performance Notes:**
67
69
-`MAX_WORKERS` controls parallelism within each scan task
0 commit comments