Feature Request: Cache “Recently Added” media

[cm86]

Hi,

first of all, thanks for this project — PlexCache-D looks really useful for keeping frequently accessed Plex media available on faster storage.

I would like to suggest adding support for caching Recently Added media.

Use case

Currently, PlexCache-D appears to focus mainly on media from areas like On Deck / Continue Watching and Watchlist. That makes a lot of sense for content with clear viewing intent.

However, another useful scenario would be to automatically cache newly added media, for example:

• newly added movies
• newly added TV episodes
• new seasons or shows
• media added within the last X days

This would be especially helpful for setups where new content is often watched shortly after it is added to the Plex library.

Thanks for considering it!
cm86

[Brandon-Haney]

@cm86
So before getting into building this, depending on your setup the caching part of this is mostly a non-issue already. In my setup all my downloads land on the cache drive first and only get moved to the array later by the Unraid mover, so newly-added content is already on fast storage during exactly the window where its most likely to get watched. And heres the key thing: PlexCache already handles caching it the moment it matters. If a recently-added item gets added to a watchlist or shows up on deck, it gets cached automatically, and if its already sitting on the cache drive, thats not even a copy, its just an exclude-list update so the mover leaves it alone. The whole caching pipeline already does the right thing.

So to me this really isnt a "cache recently-added media" request, its a visibility one. Right now that new episode genuinely is on the cache drive, but PlexCache has no idea it exists until it lands on a watchlist or on deck. From the dashboards perspective its invisible even though its already cached. Thats the actual gap. The right move isnt a new caching source, its surfacing recently-added items so you can see whats there, where it lives (cache vs array), and let the existing watchlist/ondeck flow take over from there.

Thats a feature Id actually be interested in building, because its additive visibility without the risk of a new source speculatively filling your cache with stuff nobody asked for.

Curious what your setup looks like, do your downloads already hit cache first, or are they landing straight on the array? That changes how much of this youre already getting for free.

[cm86]

Hello,

yes, my downloads do land on the cache first and then get moved into the media folder, while initially still staying on the cache.

The main issue is that I only have a 1 TB cache pool, so my Unraid mover runs daily. Because of that, recently added media usually only stays on the cache for about one day unless PlexCache knows about it and excludes it from the mover.

So I agree that this might be more of a visibility / awareness feature than a completely separate caching source.

For my setup, it would be useful if PlexCache could see recently added items, show whether they are currently on cache or array, and optionally keep them on cache for a configurable window, for example a few days, before letting the mover handle them normally.

And yes i see what you mean...

[Brandon-Haney]

Hello,

yes, my downloads do land on the cache first and then get moved into the media folder, while initially still staying on the cache.

The main issue is that I only have a 1 TB cache pool, so my Unraid mover runs daily. Because of that, recently added media usually only stays on the cache for about one day unless PlexCache knows about it and excludes it from the mover.

So I agree that this might be more of a visibility / awareness feature than a completely separate caching source.

For my setup, it would be useful if PlexCache could see recently added items, show whether they are currently on cache or array, and optionally keep them on cache for a configurable window, for example a few days, before letting the mover handle them normally.

And yes i see what you mean...

I understand, I would advise you to use the Mover Tuning plugin https://forums.unraid.net/topic/70783-plugin-mover-tuning/ , you can control how long files stay on cache before they are moved. You can tweak the settings to work for your specific setup,

I built some visibility into Recently Added (fed by Plex), see the images below. These are work in progress screens, nothing is final and I am reworking what actions to allow the user to do here.

[cm86]

yes thats right, but then he will also let other cached files on the cache which are no media files...

As PlexCache-D already knows them he just has to put the in the exclude file for the mover, so they won't be moved...

Nice work in the screenshots

[Brandon-Haney]

yes thats right, but then he will also let other cached files on the cache which are no media files...

As PlexCache-D already knows them he just has to put the in the exclude file for the mover, so they won't be moved...

Nice work in the screenshots

I'm not sure I follow, your media files are added by Radarr/Sonarr and plexcache only pays attention to items added into our path mappings along with data fed by Plex api.

Can you explain a little more your concerns?

[StudioNirin]

I wonder if this is a case where there could be a setting option for "add recently added media to plexcache" yes/no and if yes, give it a separate priority rating where it has lower priority than on-deck items but higher than old watchlist items. Or something. Something where it gets kept on cache for a while but if cache gets full it gets moved off faster than things people are actively using/wanting.

[cm86]

yes thats right, but then he will also let other cached files on the cache which are no media files...
As PlexCache-D already knows them he just has to put the in the exclude file for the mover, so they won't be moved...
Nice work in the screenshots

I'm not sure I follow, your media files are added by Radarr/Sonarr and plexcache only pays attention to items added into our path mappings along with data fed by Plex api.

Can you explain a little more your concerns?

My downloads end up in the path “/Media/Downloads”
if I move them, they end up in “/Media/Movies,” for example

Since the Mover runs every morning at 7:00 AM, they only stay on the cache until 7:00 AM the next day...

But as long as they’re on the cache and in the “/Media/Movies” folder, Plex Cache-D sees them and marks them as untracked...

[Brandon-Haney]

@cm86

Sorry for the slow reply on this. That makes sense now, thanks for spelling out the flow.

And you've got it exactly right. Anything that's on deck or on a watchlist is already protected. PlexCache picks those up and excludes them from the mover on its own. So the stuff that actually gets swept back to the array is the genuinely new content with no current demand to watch: not pinned, not on deck, not on anyone's watchlist. That's the gap.

That's also why I went the visibility route instead of a blunt hold. Mover Tuning would keep everything on cache longer, but you only care about that specific new-but-undemanded slice. The Recently Added view is built around exactly that. It lists your newly added items, shows whether each is on cache or array, and shows what's protecting it (pinned, on deck, watchlist) or flags it as on cache but unprotected, which is the one the mover grabs next run. You pin those and the mover leaves them alone.

It's on the dev branch, but still needs work and some design decisions sorted before I'd put it up as a PR, so I don't want to put a timeline on it yet. Worth knowing that pinning already works on the current release, so you can hold new items off the mover today even without the list to spot them. I'll update this thread when there's something you can pull.

[Leftyist]

Hey I have a similar issue that I think ties into the same idea. I'm not sure where you are with this work but it could be a useful data point. For context I do use mover-tuning with smart caching to keep recently added media on the cache.

I noticed that after watching something recently added, PlexCache-D automatically moved it off the cache and onto the array, which was unexpected. I was hoping that it would just remove the exclusion and allow mover-tuning to move it back later. This means that if someone else wants to watch this same recently added media, then it will spin the drives back up and potentially have to re-cache the content.

I figure this could be determined by checking if there's a matching .plexcached file on the array. Anyways looking forwards to the update!

[StudioNirin]

Hey I have a similar issue that I think ties into the same idea. I'm not sure where you are with this work but it could be a useful data point. For context I do use mover-tuning with smart caching to keep recently added media on the cache.

I noticed that after watching something recently added, PlexCache-D automatically moved it off the cache and onto the array, which was unexpected. I was hoping that it would just remove the exclusion and allow mover-tuning to move it back later. This means that if someone else wants to watch this same recently added media, then it will spin the drives back up and potentially have to re-cache the content.

I figure this could be determined by checking if there's a matching .plexcached file on the array. Anyways looking forwards to the update!

This is a good point, Plexcache shouldn't really move newly downloaded media off the cache. But it would be tricky for it to know what would qualify.

Your thought on relying on whether a .plexcached file exists for it might work. @Brandon-Haney what do you think?

As long as it gets removed from the exclusion list, they'd get moved onto the array eventually by the mover. I am trying to think if that would interfere with any other existing functionality..

[Brandon-Haney]

@Leftyist I see what you're asking for. My initial plan was to use Cache Retention (hours) set to something like 7 days, so when a user watched new content PlexCache would hold it in the exclude list until that time passed. The problem is that only delays things. At the end of the window PlexCache still copies the file to the array, and while it's being held the mover can't touch it either, so it ends up fighting whatever schedule you've set in Mover Tuning rather than working with it.

So I changed the default behavior on my branch instead. If PlexCache never pulled a file off the array in the first place, which is the case for anything that landed on cache from your downloader, there's no .plexcached backup for it. When you finish watching, PlexCache now just drops the exclude entry and leaves the file exactly where it is. No copy, no array spinup, and your mover picks it up on whatever schedule you've configured. Anything that does have a backup still gets restored the way it always has, same for hardlinked files and a few other cases where releasing wouldn't be safe.

@StudioNirin, one correction on them getting moved to the array eventually by the mover. That only holds on cache:yes. I went through the mover script to be sure, and prefer moves array to cache, the opposite direction, while only and no aren't processed at all. So there's a fallback that takes files back if the cache genuinely runs out of room while released files are still sitting there. And yes, it did interfere with one thing, the exclude file also feeds eviction and the quota, so released files were dropping out of PlexCache's own reach. That's reworked now so they stay tracked.

Still to do is surfacing the released state in the UI, since right now those files just show up under Other with nothing marking them. Once that's in and I've tested a bit more I'll put up the PR. No new settings, it's the default behavior.