V2.0 Update - Discussions

[StudioNirin]

@Brandon-Haney

Ok I've merged the latest PR into the test branch for V2.0, everything seemed to be working correctly and I couldn't find any issues. Figured I'd start a new thread for this now, maybe with a shortlist of things to test and check before V2.0 gets a proper release.

1. What files are still needed for users migrating?

We have a lot of created files, both new and old, and I'm not 100% sure which ones are still necessary. I've removed most of them just because I am going to test with a moderately fresh install.
For instance, is the 'watched_cache' and 'watchlist_cache' files still needed? We seem to now also have 'timestamps' and 'watchlist_tracker' files.
There's also a 'plexcache_user_tokens' file, though I'm not sure why this needed to be split off from the 'plexcache_settings' file which already had fields for user tags and tokens. Unless this needs to be separate for some reason, I think maybe it would be better merging it.

Basically my goal is to streamline things as much as possible. Makes it easier for people migrating etc. Your new setup file already handles migrations tidily and helps users through it.

Edit:
From what I can tell, watchlist_tracker has replaced watchlist_cache, so migrating users can delete that file. The new tracker file is also used to store the timestamps of the watchlist files for retention purposes.

plexcache_timestamps is used for.... onDeck and whatever logic is used to mark something as 'pre-existing' (I assume it's things already on cache while also being onDeck or on Watchlists(?), but I'm not sure why they're not just being marked as onDeck or Watchlist instead of pre-existing.

In fact that file seems to just be onDeck files and not watchlists, so I'm not sure why pre-existing mattered.

2. Going through the Watchlist tracker file I notice you manage to get watchlist information for remote users, which is great (not sure how you managed it, or if its accurate, but it at least seems to be correct). However I noticed you still seem to have the RSS feed being used in the code at some point, but I'm not sure what you're using it for? If you figured out getting watchlists for remote users then the RSS feed shouldn't be needed (I don't think?)

Edit: Ahh interesting, I didn't notice that the RSS feed has 'author' coding, I assume that tallies up with the user. When I figured out the RSS setup as a workaround for remote users I never found any documentation about that actually being an identifiable tag, everyone seemed to think the RSS feed was essentially 'anonymous'. Very nice!

3. I'll add more to this after I've gone through some more testing and file checks. TBD

[Brandon-Haney]

@StudioNirin
Let me clarify,

1. Data Files
   Files that can be deleted (no longer used):

   • plexcache_watchlist_cache.json - replaced by watchlist_tracker
   • plexcache_watched_cache.json - we always fetch fresh data now
   • plexcache_user_tokens.json - this was over-engineering on my part when I was working on getting user IDs for the RSS details, we can remove this and just use the tokens from settings with a quick update. (I will add to my list)

   Files still in use:

   • plexcache_settings.json - main config (includes user tokens and IDs)
   • plexcache_mover_files_to_exclude.txt - Unraid exclude list
   • plexcache_timestamps.json - tracks when files were cached (for retention period)
   • plexcache_watchlist_tracker.json - tracks watchlist items with user attribution and timestamps

   About "pre-existing" source:
   When the app starts, if a file is already on cache AND matches something on OnDeck/Watchlist, we record it with source "pre-existing" so it gets retention protection. Without this, files already on cache before the app ran would have no timestamp and could get moved back immediately. It's basically "we found this already cached, protect it."

2. RSS Feed Usage
   You're right that we CAN get watchlist info for local/home users via API. The RSS feed is specifically for remote users (friends) whose watchlists we cannot access via API.

   The flow is:

   • Local/home users -> API (full access, per-user attribution)
   • Remote users (friends) -> RSS feed (all-or-nothing, but we use the author tag to attribute items)

   I found the the RSS tag contains a user ID that maps to usernames, The user IDs are now stored in the settings file, so we just build that mapping at runtime. This lets us attribute RSS watchlist items to specific users.

   If you have NO remote users sharing your server, you could skip the RSS entirely. But for users with friends, it's the only way to include their watchlists.

[thepilzkopf]

Good Morning Everyone,

I need a small clarification on new added things with update 2.0
Previously, I got a plexcache_mover_files_to_exclude.txt File with all cached files.

Now im also getting a unraid_mover_exclusions.txt

But when running the script - both are changed.

Which one is now the right one to get checked by the mover?

[StudioNirin]

Unraid mover exclusions.

There are two files because one contains a list of cached files, and the
other has a marker where you can add in your own custom list of exclusion
files. Plexcache appendix cached files below that marker, and ignores
anything above that marker (so youd put your custom entries above it so
they dont get altered)

[thepilzkopf]

First: Thanks for Update 2.0 - it works really good and I really like the new additions like the configurable retention time e.g.

I have a Feature Request @StudioNirin / @Brandon-Haney
Im not sure if this is the right point for feature request but could it be possible to extend the log?
I really liked the old log where I could see which files where moved and so on - i used it to get an overview of everything is right.

But with this new log (mode: summary) I dont know anything.
I see in my unraid notification that 27GB where cached but which files?
In the log is only this and then "and 13 more titles" - but what are this titles?

I totally get it, that you possibly wanted to reduce the amount of information in the logfile as it was overwhelming.
But for me - its a littlebit to less now.

For me it would be totally fine if you add to the current logfile:

1. Which files where cached (filename only)
2. Show all files with open retention (filename and open retention time)
3. Which files where moved back to the array - filename only (i had none so if this is show please ignore this point)

[StudioNirin]

If you add -verbose to the script, or change logging to debug, you do get those additional lines... but I wouldn't recommend it, because it'll throw out a LOT of additional lines (something like 5000kb worth).

I agree some kind of option to turn on -just- a summary list of items might work, but it might also be a pain depending on how you view the log. The log.txt file would be fine, but if you view the log via the terminal the list of items would probably overflow the terminal limit so you wouldn't be able to scroll back to see them.

I think perhaps an option would be a separate output file with that information summarised maybe.

I am going to open a new Issue as a feature request (that's the best place for things like this as it seems to be easier for us to get notified on them, github doesn't notify us on discussions at all for some reason afaik). I'll tag you in it.

[rairulyle]

@StudioNirin @Brandon-Haney

So I made some changes with my setup. I now have 2 pools named cache and plexcache

The cache is used by the Array as primary while the plexcache is specifically used just by plexcache script.

In this case, am I right to assume that I do not have to put /mnt/user/appdata/plexcache/unraid_mover_exclusions.txt in the Mover exclusion as it is not being used as primary by the Array? What happened if an episode gets updated?

[Brandon-Haney]

It depends on your share settings - specifically the Primary storage and Mover action for your media shares.

If your media shares have:

• Primary storage: plexcache
• Mover action: plexcache → Array

Then you DO need the exclusion file - otherwise the mover will move your cached files back to the array.

If your media shares have:

• Primary storage: cache (your other pool) or Array
• Mover action: cache → Array (or disabled)

Then you don't need the exclusion file since the mover never touches plexcache. In this case, I'd recommend enabling Smart Eviction in your settings, it will automatically move files back to the array when you're done watching, keeping your plexcache pool from filling up.

Regarding episode updates: When Sonarr/Radarr upgrades a file, the old cached copy on plexcache becomes orphaned. Currently you'd need to manually identify and clean these up.

Note: The upcoming v3.0 release includes a Web UI with a Maintenance page that makes managing orphaned files much easier, one-click detection and cleanup. Keep an eye out for that! If you want to join the bleeding edge you could download the 3.0 betas to test it out, let me know if so.

[rairulyle]

@Brandon-Haney i have this setup:
Primary storage: cache (your other pool) or Array
Mover action: cache → Array (or disabled)

So I am right with my current setup then.

Yeah! I'll test out the Docker version now 💪🏻