user@argobox:~/journal/2026-01-20-the-136-million-segment-stream
$ cat entry.md

The 1.36 Million Segment Stream

○ NOT REVIEWED

The 1.36 Million Segment Stream

Date: 2026-01-20 Issue: Everything wrong with the NAS at once Duration: 3 hours of “what is happening” Result: Clean logs, flat folders, happy audiobooks


The Log Filesystem Was at 94%

I noticed the Mirach-Maia-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 /mnt/user/ 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 was very 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. Crisis averted.

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


The Triple-Nested Folder Structure

Investigation time.

/mnt/user/AudioBooks/                           <- Share root
/mnt/user/AudioBooks/AudioBooks/                <- Wait what
/mnt/user/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 /mnt/user/AudioBooks/AudioBooks/
# Modify: 2026-01-17 06:36:42
stat /mnt/user/AudioBooks/AudioBooks/AudioBooks/
# Modify: 2026-01-17 06:37:01

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

Someone ran a copy or move operation that created the nested structure. The empty folders were placeholders from an aborted sync. The two MP3 files were probably dragged there by accident.

My daughter uses Audiobookshelf. She doesn’t remember doing anything. Teenagers.


The Cleanup

Deleted from Level 2:

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

Moved the real content:

mv /mnt/disk1/AudioBooks/AudioBooks/AudioBooks/* /mnt/disk1/AudioBooks/

Instant operation — same filesystem, just updating directory pointers.

Removed the empty nesting:

rmdir /mnt/disk1/AudioBooks/AudioBooks/AudioBooks
rmdir /mnt/disk1/AudioBooks/AudioBooks

Final structure:

/mnt/user/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 /mnt/user/AudioBooks/ (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 /mnt/user/ 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.