The AudioBooks Folder That Ate Itself Three Times

System: Meridian-Mako-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 Meridian-Mako-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.

How does this happen? Best guess: someone was “organizing” the media library. When you’re managing files through a GUI without seeing the full path, AudioBooks looks the same at any depth. Drag AudioBooks into what you think is the share root… but it’s already inside AudioBooks. Do it twice over a few months, and you’ve got folder inception.

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 Meridian-Mako-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 Meridian-Mako-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 Meridian-Mako-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 Meridian-Mako-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:

Start fresh (lose metadata, listening progress, but clean structure)
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:

Remove the orphaned container
Recreate it through the Unraid Docker GUI using the existing template
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:

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

Lessons Learned

Document as you go — The log file saved me when context was lost
Verify, don’t assume — SSH in and check the actual state
Docker containers are ephemeral — The data is what matters
Empty folders are insidious — 3,582 placeholders masquerading as content
Remote systems evolve — When you’re not physically present, folder structures… change. Don’t assume the state you left it in is the state you’ll find.

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