AltMount reports download as completed to Sonarr, but symlink does not exist

[evulhotdog]

AltMount reported a download as completed and exposed it to Sonarr through the SABnzbd-compatible history API before the file was actually readable. Sonarr then attempted to import the file and failed because the path no longer existed or was no longer accessible through the AltMount mount.

Sonarr queue showed:

• Downloaded - Waiting to Import
• Unexpected error processing file

And:
Could not find file '/mnt/remote/altmount/complete/tv/foo.bar.mkv'
When clicking the import button.

However in Altmount, the item showed as completed in the queue as if it was ready to go.

AltMount logs show:

1. AltMount processed the NZB and created metadata for the virtual file:
   Created metadata for RAR extracted file
   virtual_path=/complete/tv/foo.../bar....mkv
   size=2613095172
2. AltMount marked the queue item as successfully processed and triggered Sonarr:
   Successfully processed queue item
   Triggered RefreshMonitoredDownloads
3. Immediately after, reading the file failed:
   [createUsenetReader] No segments to download
   available_bytes=1879048192
   expected_file_size=2613095172
4. AltMount then detected corruption:
   Streaming failure detected, triggering immediate ARR repair
   File corrupted
   error="missmatched segments for file size"
5. Later, AltMount removed the item from its view:
   File no longer tracked by ARR during re-trigger, removing from AltMount
6. From inside the Sonarr container, the exact path did not exist:
   /mnt/remote/altmount/complete/tv/foo.../bar....mkv

AltMount should not expose a download as Completed to Sonarr until the virtual file is confirmed readable/importable.
If the file fails segment validation, health validation, or read validation, AltMount should either:

• keep it out of SABnzbd completed history, or
• report it as failed/warning, not completed, or
• hide it consistently from fuse/webdav and ARR clients in unison.

[javi11]

did you have 100% segment validation? if not, there may be cases where you get corrupted files after import

[firestaerter3]

Ran into the same gap. When altmount removes an item from tracking after a corruption/repair cycle, there's no signal back to the ARR - Sonarr is left with a stale importPending entry it can never resolve on its own.

The fix direction seems straightforward: when altmount removes an item from its queue during repair/re-trigger, mark it Failed in the SABnzbd history response (or push a webhook) so the ARR clears it through its normal failed-download path rather than waiting indefinitely.

[evulhotdog]

did you have 100% segment validation? if not, there may be cases where you get corrupted files after import

@javi11 Yep!

I'm a little on the newer side to Usenet as a whole.

The idea I had was that I should be validating all segments on import to ensure the file is playable, although my media player scans for intro / outro as well, so maybe it's not actually relevant, depending on how it's seeking within the file itself and what that actually maps to in Usenet.

Anyways, are there more or less ideal settings for this?

@firestaerter3 I think the core issue is that segments are missing but it's being marked as completed, I do think this would help address dangling imports in Sonarr, but does not resolve the root problem of why it was errored in altmount to begin with.

[drondeseries]

What's your rclone flags?
attr_timeout: 1s
dir_cache_time: 10s

[evulhotdog]

What's your rclone flags? attr_timeout: 1s dir_cache_time: 10s
@drondeseries

rclone
	mount
	"altmount:"
	/mnt/remote/altmount
	--vfs-cache-mode=minimal
	--vfs-cache-max-size=5G
	--vfs-cache-max-age=2h
	--buffer-size=16M
	--vfs-read-chunk-size=32M
	--vfs-read-chunk-size-limit=2G
	--dir-cache-time=10s
	--allow-other
	--allow-non-empty
	--links
	--umask=002
	--uid=1000
	--gid=1000
	--cache-dir=/cache/rclone
	--log-level=INFO