Skip to main content
Back to Journal
user@argobox:~/journal/2026-01-20-the-136-million-segment-stream
$ cat entry.md

NAS Media Library and Log Hygiene Cleanup

○ NOT REVIEWED

NAS Media Library and Log Hygiene Cleanup

Date: 2026-01-20 Issue: Log pressure, noisy remote mounts, and media-library path drift Duration: 3 hours of focused cleanup Result: Clean logs, flat folders, happy audiobooks


The Log Filesystem Was at 94%

I noticed the Meridian-Mako-Silo NAS was sluggish. Quick check:

df -h /var/log
# Filesystem      Size  Used Avail Use%
# /dev/sdb1       1.0G  940M   84M  94%

94% on the log filesystem. Not great.

lsof +L1 /var/log
# rsyslogd 1770 root /var/log/syslog (deleted) 117,828,818 bytes

rsyslogd was holding a 112MB deleted file open. The file was gone, but the process still had a handle to it, and the space wouldn't be freed until rsyslogd let go.

kill -HUP $(cat /var/run/rsyslogd.pid)

One signal, and the log filesystem dropped to 6%.


The Remote NAS Log Spam

But why was the log filling up so fast?

Dug into the syslog and found the culprit: Unraid's emhttpd daemon was continuously trying to read extended attributes from the remote NAS mounts (Caph-Silo and Matar-Silo, connected via rclone). The problem? Those mounts are rclone FUSE, and FUSE doesn't support xattrs.

Every attempt to read xattrs logged an error. About 172,800 errors per day. Two errors per second. Forever.

The bandaid fix:

# Added to /etc/rsyslog.conf
if $programname == "emhttpd" and $msg contains "getxattr" then stop

The real fix (for later): Move the rclone mounts out of the user-share tree so emhttpd stops scanning them. For now, the filter keeps the logs from exploding.


The Audiobook Stream That Broke Reality

While I was on the NAS, I checked Audiobookshelf. Memory usage: 10GB and climbing.

docker stats audiobookshelf --no-stream
# CONTAINER     CPU %   MEM USAGE
# audiobookshelf 95%    10.2GiB

Something in the library path was wrong.

The logs told the story: Someone had clicked play on "The Crossing (UAB)" at 15:12. Audiobookshelf responded by attempting to stream 1,363,310 segments.

1.36 million segments. 2,272 hours of audio. FFMPEG had been running for hours, desperately trying to transcode what it thought was a single audiobook.

docker exec audiobookshelf pkill -9 ffmpeg

Memory dropped. CPU calmed down. The immediate resource pressure was gone.

But what made Audiobookshelf think one audiobook was 2,272 hours long?


The Triple-Nested Folder Structure

Investigation time.

AudioBooks/                           <- Share root
AudioBooks/AudioBooks/                <- Wait what
AudioBooks/AudioBooks/AudioBooks/     <- Oh no

The audiobook library had grown a triple-nested structure. The real content — 4,630 audiobooks, 3.5TB — was buried at the third level.

The second level had 3,584 empty folders. Plus two rogue MP3 files that were duplicates of books in the real library.

Audiobookshelf was configured to point at level 2. Which meant it was trying to concatenate the entire folder tree into one stream whenever someone hit play.


The Archaeology

Checked the timestamps on the nested folders:

stat AudioBooks/AudioBooks/
# Modify: 2026-01-17 06:36:42
stat AudioBooks/AudioBooks/AudioBooks/
# Modify: 2026-01-17 06:37:01

Both created on January 17th, within one minute of each other.

A copy or move operation had created the nested structure. The empty folders were placeholders from an aborted sync, and the duplicate MP3 files were leftover content that needed cleanup.


The Cleanup

Deleted from Level 2:

  • (Duin 2) Duin messias - Frank Herbert.mp3 — 364MB duplicate
  • (Duin 3) Kinderen van Duin - Frank Herbert.mp3 — incomplete duplicate (Level 3 had the complete file)
  • 3,584 empty folders

Moved the real content:

mv AudioBooks/AudioBooks/AudioBooks/* AudioBooks/

Instant operation — same filesystem, just updating directory pointers.

Removed the empty nesting:

rmdir AudioBooks/AudioBooks/AudioBooks
rmdir AudioBooks/AudioBooks

Final structure:

AudioBooks/   <- 4,639 audiobooks (3.5TB) - FLAT

The Reset

Audiobookshelf needed a fresh start:

  1. Stopped the container
  2. Updated the docker config to point at the flat AudioBooks/ share path, not the nested path
  3. Backed up the old database
  4. Created fresh config directory
  5. Recreated the container

She'll need to set up her library again, but at least it won't try to stream 2,272 hours when she clicks play.


The Lessons

rsyslogd holds deleted files open. A HUP signal releases them.

Unraid's emhttpd scans the user-share tree constantly. Don't put FUSE mounts there unless you want 172,800 error messages per day.

Triple-nested folder structures break Audiobookshelf spectacularly. It concatenates everything it can find into one stream.

Kids don't remember moving files. Always check timestamps for forensics.

FFMPEG will try its best. Even when "its best" means transcoding 2,272 hours of audio at once.


When your audiobook player thinks a single book is longer than the Lord of the Rings audiobook repeated 20 times, it's time to check your folder structure.