Feature Ideas & Discussion: What's Next for PlexCache-R? #56
Replies: 18 comments 45 replies
|
@StudioNirin tagging you for review when you have a moment. Feel free to add anything I missed. |
|
@Brandon-Haney Decided copying the whole thing and then adding comments in-line was the easiest way haha - Nirin What would be most useful to you? What's missing? What's unnecessary? Ideas Under Consideration1. OnDeck/Cache Tracking ImprovementsProblem: The OnDeck tracker is cleared each run, losing context of what was previously OnDeck. This causes misleading logs ("Added new OnDeck entry" for files already on cache) and inefficient processing. Idea:
Benefits: Smarter eviction candidates, better notifications, progress detection.
2. Configurable Priority ScoringProblem: Priority weights for eviction are hardcoded (OnDeck bonus +15, user count bonus +5/user, etc.). Users can't tune behavior to their viewing habits. Idea: Add Settings → Cache → Priority Tuning section with sliders/inputs for:
Integration: Could extend the Eviction Simulator to preview how weight changes affect cached files.
3. Optional Mover Exclusion FilesProblem: PlexCache creates mover exclusion files for everyone, but only users with the CA Mover Tuning plugin actually need them. This creates unnecessary files and confusion for users who don't use that plugin. Idea:
4. Overseerr Integration (Wanted Items)Problem: When users add items to their Plex Watchlist that aren't in the library, there's no automatic way to request them. Idea:
Workflow:
5. Time Format Setting (12h/24h)Problem: All timestamps display in 24-hour format. Some users prefer 12-hour AM/PM format. Idea: Add dropdown in Settings → Logging for time format preference. Server-side Jinja2 filter handles formatting. Complexity: Low - straightforward implementation.
6. Maintenance Page Tile ClarificationProblem: Current tiles are confusing:
Idea:
7. Bulk Maintenance Operation Progress & ParallelizationProblem: Running "Keep on Cache" on 200+ files shows only "Processing..." with no progress. Operations run sequentially even though we have concurrency settings. Idea:
What Do You Think?
Ideas I've Ruled Out (for now)These came up but I don't think they're worth pursuing:
Disagree? Let me know if you think any of these deserve another look. |
Proposal 9 - Reactive Disk-Aware Caching - Feasibility studyJust using this as the place to figure out what might work on this. Feel free to ignore all this, I just wanted somewhere to work things out in my head lol. @Brandon-Haney Issue1 - Spin-up StatusI went through some options, and there's a few ways I've checked, but most of them go via using But I don't think the disks retain their sda / sdb / sdc etc naming in between reboots I think they're just assigned during boot. So it makes it a bit complicated to match up the tag to the right disk (let alone the right file). However I came across something that -might- work - There's a file called disks.ini which actually gives you all the info I think you'd need, plus the actual title of the disk (disk1, disk2, parity1, hex-drive) is shown as well. I've checked out the file and it's pretty straightforward. It's accessible via Terminal using: And as the docker container is always running (unlike the old userscript version) we wouldn't need any weird iNotify triggers or monitoring for file changes. The file lives on RAM anyway. So we can just have the container read that file once every minute (or 5 minutes or whatever) and look for I think if something like this is used: Then the file is read only, and there's no security risks or anything (afaik). I dunno... this seems like it might work? Issue 2 - Matching up Files to Disks.Ok so my first attempt at writing this went though some pros and cons of doing scans for files etc, because of only being able to scan or know what's on a disk when it's spun up, otherwise you'd be spinning up disks. But turned out it doesn't matter at all. So doing something like - Will output the disk that file is on, without waking up any disks. And I just tested this: And it immediately output an entire JSON of every file in the /media folder on all of my hard drives in under a second. All 40,000 of them. And each of them has a label for disk1 / disk2 etc. And none of my disks spun up. So (I would think) the way plexcached could do it, would be to do it's current search for a file, but check it in the database first, and if it's on a spun-up disk then do the moves. If it's not, then skip. This is assuming you're searching via /mnt/user or /mnt/user0 Or I guess you could just get the filename from plexcached, but only search via the number of the current spun up disk (eg. disk2) and if it can't be found, skip. And if it is found, then do the movement. I think all the unraid/plex file system stuff will still be fine if you move a file to/from cache via /mnt/disk2 instead of the /mnt/user or /mnt/user0 version, it'll sort itself out. I don't know which method works out more efficient, but they should both work. FeasibilitySo.... actually I think this could work. I'm not saying it should be a priority, there's a whole bunch of other stuff we need to get working first, but I -think- this might be possible for a v4 release. If we decide it's actually worth all the effort anyway! Plus I'm probably missing a bunch of issues and negatives, and I have no idea if all this will actually work the way I think it will. |
|
For 4, Just an FYI. @Brandon-Haney @StudioNirin Overseer can track Plex user watchlist and auto request and download it with the respective user who requested but you have to apply a hotfix to the image manually as they no longer update Overseer to give way to Seer. For a permanent fix, you have to change to to Seer image and use the develop tag which includes Overseer migration. Feel free to check their README. |
|
I haven't set up docker releases before, do I need to set something up for
the ghcr docker releases or is it automatic?
…On Thu, 12 Feb 2026, 19:46 Brandon Haney, ***@***.***> wrote:
I have now made some new branches:
- an LTS version of v2.1.2 which is the PlexCache-R script version,
which I'll try and keep bugfixed (at least for a while) for people who like
to use the script version instead
- a v3 branch called PlexCache-D which is the docker merge. If we can
get a working merge there anyway.
Nice, those branches make sense. Here's where v3.0 stands:
What's ready:- Full Web UI with dashboard, scheduler, maintenance tools,
and setup wizard
- Docker image auto-builds via GitHub Actions CI/CD (pushes to GHCR on
every commit to v3.0)
- 381 automated tests running in CI on every push/PR
- All the safety fixes we've been working on (FUSE bug, ZFS support,
shell injection fix, eviction safety, etc.)
Flexibility, worth calling out that v3.0 isn't Docker-only. It runs three
ways:
- Docker: container with web UI, ideal for Unraid (port 5757)
- Manual + Web UI: python3 plexcache.py --web for people who prefer
native installs
- CLI only: python3 plexcache.py with cron/User Scripts, no web server
needed
So the LTS v2.1.2 script users could also upgrade to v3.0 and keep using
CLI-only mode if they want — they'd just get the bug fixes and new features
without needing Docker.
I'll PR my v3.0 branch into your PlexCache-D branch so you can review the
full diff. Once that looks good, might be worth posting on reddit to get
some beta testers on it before tagging a release. The CI pipeline will
auto-build tagged releases with proper Docker tags (:v3.0.0, :latest, etc.)
so publishing is just a git tag away.
—
Reply to this email directly, view it on GitHub
<#56 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4T22JNAA7NKBTNVEZBZCL4LTKBFAVCNFSM6AAAAACSBZIRHKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZYG4ZDANQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I am considering the benefits of applying for it to end up as an unraid
community app at some point, but that'll be a problem for another time.
Ill take a look at this merge this evening and report back
…On Thu, 12 Feb 2026, 23:12 Brandon Haney, ***@***.***> wrote:
It will be automatic once you merge in the PR, you can review the file
that handles it here .github/workflows/docker.yml
<https://github.com/StudioNirin/PlexCache-R/pull/75/changes#diff-3f5366f6d6df3ec1179e5efadc6f350bfa88eebf4e2da589b4d94ccb85ae5e94>
The only thing you need to do manually is create a docker account repo if
you want them hosted on docker itself. This is not required and completely
optional. If you go down this route then you will need to add a few repo
secrets, let me know and I can provide more details instructions if so.
—
Reply to this email directly, view it on GitHub
<#56 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4T22KQKB6EG5EDFMIZ5U34LUCGDAVCNFSM6AAAAACSBZIRHKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZYHA3DKNY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@Brandon-Haney I decided to test your PlexCache 3 docker container against a sacrificial library and wanted to offer some feedback. First of all, the web UI is amazing. It has a wealth of information for identifying what content has been cached and for which user, and offers to many options for configuring and maintaining the plexcache. I'm experiencing an issue with caching from /mnt/user/media/tvshows-dad to /mnt/cache/tvshows-dad. This works properly with PlexCache 2.1. It's copying the media from the array to the cache drive, but is then renaming the media on the cache drive to .plexcached.
Should it not be renaming the media on /mnt/user0 (the array) as opposed to /mnt/user (the share which includes array and cache)?
|
|
@StudioNirin Thinking about something we should add to the roadmap: Web UI Authentication. Right now the web UI has no authentication. Anyone with network access to the port can view settings, trigger operations, modify path mappings, browse the filesystem, and download logs. We have CSRF protection but that's it. PlexCache is designed to run on a private home network and we're not recommending it be exposed externally, but some users will put it behind a reverse proxy anyway. We should offer reasonable protection for those who want it. Proposal: Optional Web UI AuthenticationAuthentication (Settings → Security):
Session Management:
Security Hardening (bundled):
Thoughts on priority? I'd put this around P3, not urgent since most users are on private networks but worth doing before any community app listing. |
|
Is there a way to implement a per user days to monitor ondeck items? Like i might want mine to go 90 days but my friends user account only 30 days. |
|
This might be of interest. I created this based on a Python script I used to run to combine multiple exclusion lists into one. Much of the HTML was vibe-coded, but the original script was not. Essentially, this tool takes files listed in Sonarr/Radarr and adds them based on specific tags. It also allows you to include folders and other exclusion lists, so Mover Tuning will exclude those files when it runs. Feel free to take a look and see if this is something you’d like to incorporate into your container. |
|
Not sure if this is the right place to comment, but I have a feature request. Add a section where an entire TV series (or specific seasons/episodes) can be specifically cached. I know of a lot of people who have their favorite TV series on as background or white noise when falling asleep. Still testing this out, but this is very close to what I was hoping to find to minimize the disc run-times. Nice work! |
|
Hi, this is a webUI question/request. Is there a way to color code the USERS column to different colors for different users, right now all user names are green. either customizable colors by the end user or automatically. For me it would be easier to differentiate users quickly by color. Just a suggestion i thought of. |
|
Hello! I'm really interested in using PlexCache-D, but I'm a little concerned giving it full read/write access to everything on the server. Is it possible to only mount certain shares? I tried setting it up like that a few months ago, but didn't have any success. |
















Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This discussion tracked feature ideas during v3.0 development. Updated March 2026 to reflect current status — most items have been implemented.
What should we prioritize next? What's missing?
Status Summary
Implemented
1. OnDeck/Cache Tracking Improvements
first_seentimestamps to know how long items have been on OnDeck5. Time Format Setting (12h/24h)
6. Maintenance Page Tile Clarification
7. Bulk Maintenance Operation Progress & Parallelization
max_concurrent_moves_arraysettingOutstanding
2. Configurable Priority Scoring
Priority: Low — refining defaults through testing first.
Problem: Priority weights for eviction are hardcoded (OnDeck bonus +15, user count bonus +5/user, etc.). Users can't tune behavior to their viewing habits.
Idea: Add Settings → Cache → Priority Tuning section with sliders/inputs for:
Integration: Could extend the Eviction Simulator to preview how weight changes affect cached files.
Team Feedback: Keep as "Advanced Settings" for power users only. A page of sliders would confuse most users. Maybe expose in a separate advanced settings submenu once defaults are well-tested.
3. Optional Mover Exclusion Files
Problem: PlexCache creates mover exclusion files for everyone, but only users with the CA Mover Tuning plugin actually need them. This creates unnecessary files and confusion for users who don't use that plugin.
Idea:
Note: Platform-specific terminology was already implemented (non-Unraid users see generic terms instead of "Unraid mover", "array", etc.), but the toggle to skip file creation entirely is still outstanding.
Future Consideration
8. Smart Episode Count (Nirin's Idea)
Problem: Caching uses a fixed episode count regardless of whether a show is being actively watched or how long episodes are.
Idea: Vary the number of cached episodes based on:
Prerequisite: Depends on #1 (OnDeck Tracking) which is now implemented, so the groundwork is in place.
9. Reactive Disk-Aware Caching (Nirin's Idea)
Problem: PlexCache spins up all disks on a schedule (e.g., midnight). If disks are already spun up by other processes during the day, PlexCache could piggyback on that instead of causing additional spinups.
Idea:
/var/local/emhttp/disks.ini(mount read-only into container) to detect disk spin stateFeasibility (Nirin's research):
disks.inihasspundown="0"per disk, readable without spinning disksfind /mnt/disk*works without spinups (with Dynamix Folder Caching plugin)-v /var/local/emhttp/disks.ini:/unraid/disks.ini:ro(read-only, no security risk)Status: Research phase. Potentially a v4 feature. Docker-only (requires Unraid host).
Deferred
4. Overseerr Integration (Wanted Items)
Deferred: Seerr now handles Plex watchlist → request automation natively (see comment from rairulyle). Out of scope for a caching tool.
Ruled Out
Disagree? Let me know if you think any of these deserve another look.
All reactions