Wanted to post this here since I didn't get much of any results for UnRaid searching the forums for ChannelsDVR's site (tho their forums are great and the Dev's are VERY responsive) -- that said, of course would not expect FancyBits (Channels DVR official vendor template that's in CA) to necessarily post in UnRaid forums, but I found I was rapidly eating up to max docker.img size by Channels writing into the .img file and was confused why since I've used Channels DVR successfully for a long time.

To be specific, I installed "channelsdvr_intel" from Squid's app store (timstephen24's repo) after adding an A100 discrete GPU and of course the Intel GPU Top plugin (AV1 encoding is now insanely fast!) - but that said, the current app store templates all seem to be sourced from the fancybits main dockerhub.

Problem

Channels DVR Docker container was filling up docker.img, triggering disk usage warnings and became apparent by recordings showing "interrupted" on the Channels DVR GUI - and of course via UnRaid server warnings (by using just the default template settings / mappings), tho it's interesting that the GUI doesn't necessarily offer easy ways for novices to debug that. Not sure what's changed on Channels side, as I've used this for years successfully, but just going with the default template as is I don't think currently is a good idea

Solution Summary

Added proper path mappings to keep Channels DVR data out of docker.img by properly mapping container paths to array/cache/RAM storage after Claude helped me debug what it was doing.

(My) Final Working Configuration (yours may vary of course)

Path Mappings [left = container path, right = host path]:

• /channels-dvr → /mnt/user/Video/Channels/Database/ (DVR database/index)

• /recordings → /mnt/user/Video/Channels/Recordings/ (permanent recordings)

• /tv → /mnt/cache/appdata/channels-dvr/TV_Buffer/ (live TV buffer on cache SSD)

• /tmp → /tmp/channels-dvr-temp/ (temp transcodes in RAM)

Here's how (thanks Claude....) I tracked this down

Key Diagnostic Commands (from main UnRaid terminal prompt)

1. Check docker.img actual usage:

bash

df -h | grep docker

2. Verify container path mappings are active:

bash

docker inspect <container_name> | grep -A 5 Mounts

3. Check container size vs actual storage (again, Video is the share I have Channels mapped to, yours may vary as above, adjust accordingly):

bash

# Shows container "size" (misleading - includes bind mounts)
docker ps -s

# Shows actual size on host (what really matters)
du -sh /mnt/user/Video/Channels/Database/

4. Find what's using space inside container (yet again, depends on your actual template mapping choices of course, mine shown here to match my above mappings):

bash

docker exec <container_name> du -sh /channels-dvr/ /recordings/ /tv/ /tmp/

5. Monitor docker.img size over time:

bash

watch -n 5 'ls -lh /mnt/user/system/docker/docker.img'

Critical Step in my case: choose "Force Update" from Docker config page after adding the mappings (**I'm curious if this is common or should be standard practice with template edits - seemed strange to have to do this if the docker is stopped?)

Why Force Update was needed:

• Just adding path mappings to the template and clicking "Apply" doesn't always recreate the container with new mounts - at least it didn't for me.

• The container was running with the old configuration (no /tmp mapping visible in docker inspect), so even after "Fixing" and restarting the docker, it still wasn't behaving properly

• Force Update recreates the container with the current template settings

How to Force Update:

1. Stop the container

2. Docker tab → Click container icon → Select "Force Update"

3. Container recreates with all current template mappings active

4. Verify with docker inspect <container_name> | grep -A 5 Mounts

Results

• docker.img usage: 7.2GB / 200GB (4%) - down from near capacity moments earlier

• 13GB of Channels DVR data now properly stored on array

• No more docker.img warnings

• Temp transcodes use RAM instead of disk (great If you have large RAM to spare - otherwise map the /tmp to /mnt/cache [etc] instead of to RAM)

Key Lesson

The docker ps -s SIZE column is misleading - it includes bind-mounted data. What matters is:

1. Actual docker.img usage: df -h | grep docker

2. Verifying mounts are active: docker inspect

3. Checking data is on host paths: du -sh /mnt/user/...

The Below is More FYI from questions Claude helped answer while bashing around (48 GB RAM in my system that's available to Docker):

Recording Storage / Live (time shift) pause/restart DVR Requirements [note that live record cache size is configurable in Channels GUI]. I don't mind handing over most of the server resources for this in my use case - including most of the cores to grind thru ComSkip on the cached transcode - so all the better to have it in RAM.

Typical recording sizes (varies by source quality):

• HD content: ~2-4 GB per hour

• SD content: ~1-2 GB per hour

Example scenario:

• Recording 3 simultaneous HD sports games for 3 hours each

• Total storage needed: ~18-36 GB

• With 48GB RAM for temp transcodes: Plenty of headroom for live transcoding during playback

Why this matters:

• During testing with 3 active recordings, we saw RAM growing by ~8MB every 3 seconds for temp transcode buffers (3 live recordings)

• The 13GB in /channels-dvr/data/recorder.idx/ was accumulated over months of recordings from September through December

• This data is stored in Channels DVR's proprietary .seg (segment) format in the recorder index

Storage growth rate to expect:

• Active recordings: 30-60 MB/minute per stream (depending on quality)

• Commercial detection: Adds minimal overhead when enabled (# of CPU cores to use is configurable)

• Temp transcodes: Use RAM temporarily, auto-cleaned after playback stops

Final sidebar / tangent, essentially fanboy comments about Channels DVR:

For newbies to Channels DVR, the GUI is very extensive and I've watched the Channels Devs (it's a paid app but they pay it forward!) in past few years really dial it in to the user feedback (deliberate exact opposite of Plex !!!!), so you can really dial this in over time as you learn what you like. But most importantly as you do so, note that you can choose to backup the database file elsewhere (IE out to the array) and make it easy to copy it out to import it into a new machine setup, or resurrect your perfect config if you have to nuk & pave, etc. -- esp. helpful if you've successfully mapped favorites for OTA TV station setup, various preference settings, mapped the "TV Anywhere sources (streaming subscriptions mapped to synthetic "Cable TV" channels in your Guide etc. etc. Also be sure to take advantage of "TV Anywhere" making DVR of your streaming service (DirecTV, YoutubeTV, etc.) possible (and awesome). This and the ability to do comskip for say sports shows while still recording them is a real Chef's Kiss touch as well if like me you like to delay start and catch up to the live broadcast sans commercials. Another favorite of mine, for very cheap $ per video, use PLAY ON (Cloud) where you buy credits and essentially pay a Playon Bot to "watch" a video for you (logged in on your behalf) and use their downloader to then drop it down to your sever - perfectly legal for personal use, and it watermarks the first few seconds showing that it's you recording for your own personal use, but otherwise it's just the video (only caveat is a large number in front of the file name). However Channels is PlayOn import friendly if you point it to the target of those downloads as another "source" library. Lots of advantages for example if you want to subscribe to Disney, mass "watch" the Star Wars series / movies etc, then suspend or end the subscription so you don't rack up service charges you're not using. Good for Netflix, Amazon Prime TV, Peacock Paramount and many others. PlayOn will also do Comskip and grind them out of the recordings for you where relevant - very accurately !

Edited December 16, 2025Dec 16 by jsdoc
edited for accuracy & additional detail

This probably goes without saying, but to be noob complete (and resolve your overloaded docker.img file), one can go to UnRaid Settings -> Docker, Stop docker, checkbox the "delete docker.img" option, execute that, and restart docker -- will of course have to reinstall all your active docker apps, but UnRaid has made that easy peasy by keeping the templates available for you (obviously make note of / screenshot your template names as needed in case you may have multiple legacy versions, etc. so you reinstall the right ones...)

Step by step:

1.     Go to Settings → Docker (Advanced View on)

2.     Set Enable Docker: to No

3.     Click Apply → Docker service stops

4.     Note (change if desired) Docker vDisk size to your new desired size (e.g., 30G, 300G, whatever's relevant to your setup). As large as most folks disk arrays are these days, 30-50G (or 100G if your array is black hole sized lol) seems to be the popular default

5.     Tick the checkbox Delete vDisk file (step #4 / #5 only becomes available after Docker is disabled via step 2)

6.     Scroll down and execute the deletion

7. Re-enable docker, click apply (Docker tab should reappear, can reinstall the docker templates)

Back to your regularly scheduled DVR Program.......

Edited December 16, 2025Dec 16 by jsdoc
clarification