ArgoBox
ArgoBox Infrastructure & Automation
user@argobox:~/journal/2026-01-21-the-audiobooks-folder-that-ate-itself-three-times
$ cat entry.md

The AudioBooks Folder That Ate Itself Three Times

[Wednesday, January 21, 2026] MOOD: DEBUGGING Unraid 6.x
○ NOT REVIEWED

The AudioBooks Folder That Ate Itself Three Times

System: Mirach-Maia-Silo (192.168.20.50) - Unraid array Status: RESOLVED (eventually) Duration: Several hours (context was lost mid-task) Data at Risk: 3.5TB of audiobooks Lesson Learned: Check your folder structure before you start moving 4,630 directories

You know that moment when you’re in the middle of a complex file reorganization, Claude Code loses all your context, and you have to reconstruct what Past You was doing by reading docs like an archaeologist?

Welcome to my 1:45 AM on January 21st, 2026.

The Discovery: Folder Inception

I had been working on Mirach-Maia-Silo (my Unraid array), reorganizing the AudioBooks share. What I thought was happening: “I’m moving some files around.”

What was actually happening: I was unwinding a three-level-deep folder structure that looked like this:

AudioBooks/
├── AudioBooks/           ← Level 2: 3,582 EMPTY FOLDERS + 2 duplicate files
│   └── AudioBooks/       ← Level 3: 4,630 ACTUAL AUDIOBOOKS (3.5TB)

That’s right. AudioBooks/AudioBooks/AudioBooks/.

Because if one folder is good, three must be excellent.

The Amnesia

When I came back to the task, Claude had lost all context. I didn’t know:

  • What we were moving
  • Where we were moving it to
  • Whether the move was complete
  • Whether the database was updated

All I remembered was: “I was doing something with AudioBooks on Mirach-Maia-Silo” (the hostname before galactic sanitization).

My first instinct? Search my home directory for AudioBooks folders. Zero results. Of course — this is Unraid, and I’m on a different machine. The files are on the array.

The Investigation

Step 1: Where the hell is Mirach-Maia-Silo?

ping 192.168.20.50
# Alive. Good.

Step 2: What shares does it have?

smbclient -L 192.168.20.50 -N
# AudioBooks share exists. Okay.

Step 3: What does the documentation say we did?

I found Mirach-Maia-Silo-LOG-FIX-BANDAID.md in my Documentation folder. Timestamp: 2026-01-20 (earlier today).

The doc said the work was COMPLETED:

  • Logs fixed (rsyslogd was holding a deleted 112MB file)
  • Synology getxattr spam suppressed
  • Audiobookshelf runaway stream killed
  • AudioBooks triple-nested structure FIXED

But was it?

The Verification

SSH’d into Mirach-Maia-Silo to check:

ls /mnt/user/AudioBooks/ | wc -l
# 4638

du -sh /mnt/user/AudioBooks/
# 3.5T

Good. That’s the right number. Let me check if any nested folders still exist:

find /mnt/user/AudioBooks/ -maxdepth 2 -type d -name "AudioBooks"
# (no results)

No nested folders. The move was complete.

Let me verify the actual content (not just placeholders):

ls /mnt/user/AudioBooks/ | head -5
# 01-genesis
# 02-exodus
# 03-leviticus
# ...

ls /mnt/user/AudioBooks/01-genesis/
# 01-genesis.m4b
# cover.jpg
# metadata.json

Real files. Real audiobooks. Not placeholders.

The data was safe. Past Me had successfully flattened the structure from three levels to one.

The Database Problem

But there was a catch. The Audiobookshelf container had been recreated with a fresh database.

ls -lh /mnt/user/appdata/audiobookshelf/
# absdatabase.sqlite           356K  ← Current (empty)
# absdatabase.sqlite.bak-20260120  107M  ← Old (had all metadata)

The old database referenced the nested AudioBooks/AudioBooks/ path. The new database was empty and pointed to the flat /audiobooks path.

Options:

  1. Start fresh (lose metadata, listening progress, but clean structure)
  2. Restore old database (keep progress, but risk path mismatches)

I chose option 1. The path change was too significant — better to rescan and re-match metadata than fight with broken paths.

The WebUI Button Mystery

Final twist: The Unraid GUI no longer showed a WebUI button for Audiobookshelf.

Why? The container had been recreated via docker run instead of through the Unraid GUI, so Unraid didn’t recognize it as “its” container.

The fix:

  1. Remove the orphaned container
  2. Recreate it through the Unraid Docker GUI using the existing template
  3. The template was already updated with the correct /mnt/user/AudioBooks/ path

One small problem: I told Claude to remove it, then immediately said “don’t remove it” — but it was too late.

Fortunately, Docker containers are ephemeral. The data (config, database, metadata) was still on disk at /mnt/user/appdata/audiobookshelf/. I could recreate the container safely.

The Resolution

What was moved:

  • 4,630 audiobooks from AudioBooks/AudioBooks/AudioBooks/ → AudioBooks/
  • 3.5TB of data

What was deleted:

  • 3,582 empty placeholder folders at level 2
  • 2 duplicate Duin mp3 files

What remains:

  • Flat structure: 4,638 items in /mnt/user/AudioBooks/
  • Fresh database (need to rescan library)
  • Clean container template in Unraid GUI

Next steps:

  1. Go to http://192.168.20.50:13378
  2. Create new admin account
  3. Add library pointing to /audiobooks
  4. Start library scan (this will take a while — 4,638 folders to process)

Lessons Learned

  1. Document as you go — The log file saved me when context was lost
  2. Verify, don’t assume — SSH in and check the actual state
  3. Docker containers are ephemeral — The data is what matters
  4. Empty folders are insidious — 3,582 placeholders masquerading as content

And most importantly: Don’t panic when Claude loses context. The files don’t care about AI memory. They’re still there, exactly where Past You left them.

Session recovered from Claude Code conversation transcript AudioBooks structure: FLAT Database: FRESH Panic level: MINIMAL