Add Tautulli integration #1280
Add Tautulli integration #1280
Conversation
|
Hey! First of all, thank you so much for contributing. I've been wanting to add Tautulli for a while but just haven't had the time to tackle it myself. I took a quick look at your code, and it looks really solid! I was initially concerned about stuff like caching being forgotten, but it seems like you've got that covered. I do have a few questions, but I'd like to test things out a bit more on my end before raising them as potential issues. Mainly these:
Thanks again for your work! Looking forward to getting this merged! Edit: Oh, and the proposed changes to settings.json & the formatter are fine for me. I haven't really looked at them for a long time, i'm sure there are improvements that can be made in that regard. |
|
Thank you for the feedback!
These are thrown inside the try so they'll be caught a few lines below, unless Nest is doing something extremely bizarre 😆
Ah right good to know. I'll test this later and see if I can add a TypeScript guard in to prevent dupes if that turns out to be the case. EDIT: |
|
If you need any testing done let me know. I am currently on the Dev version that is through dockerhub via Container Station (jorenn92/maintainerr). |
That would be good! @jorenn92 I can rebase & squash my commits down to get this ready for a merge if you're happy? I can write some docs for this too, how are they populated? |
Yep, you're right. This is a non issue. I should've checked before bringing this up.
Yes, they should be fine. It's possible this issue was specific to earlier versions of Nest. We'll merge it with the error messages as they are. If testing reveals that the server does crash, we can adjust them later. I tested your branch locally, and everything seems to be working well. Once you've rebased, I'm okay with merging and letting users of the dev image test it further. The documentation is housed in a different project. You can push a PR to https://github.com/ydkmlt84/Maintainerr_docs, so @ydkmlt84 can merge it. Thanks again for the great work! |
benscobie
force-pushed
the
feat-tautulli-integration
branch
from
6309a17
to
dd3dc7a
Compare
|
First wanted to say great work guys! this Tautulli integration I think is something that will help a lot of people. :) @jorenn92 I see the new tautulli option now in the settings and I had no issues getting that connection setup.
Example from Tautulli -> Libraries -> Library Name -> Media Info (not sure where in the api this is exactly), but this would give all 3 of the additional items info:
|
|
I actually was able to find the API for the total plays: |
|
@gold007eye Thank you for the feedback, I'll have a look at an implementation of those rules later today. |
|
@gold007eye For the Last view date, were you thinking that this would be the last time somebody fully watched (according to Tautulli) the content? This would align with Plex in a way. I was thinking as Tautulli returns all history there's the possibility of another rule where it's the last time somebody watched the content no matter how long for. |
|
Yeah I think, personally, that it's important to use Tautulli for the things Plex doesn't do or doesn't do what we think is correctly. No need in making two of the same things and having people ask more questions I have to answer. It should be clear what the differences are between the two options and when to use one or the other. |
|
New PR over here which adds the remaining Plex rules that relate to dates & watch percentage to Tautulli. |
@benscobie I think an option either way would be good.. I could see use cases both ways where the user could select that as the rule. Example here: I would actually personally have a rule consider that this was actually last viewed on 08-29-2024 vs going be the full 100% which would say this was last viewed 5-20-2023 over a year prior.
|
I agree with this.. Plex and it's changes to what it thinks users wants leaves big holes in things.. My perfect example. Years ago I had setup folders for "movies - franchise" as Movies - Franchise --> Franchise Name -- MovieName.ext this worked fine for plex, but recently I decided to remove that extra folder layer and leave all movies in the main folder (this wiped out ALL history per Plex for these (even though I followed their move guide to a T)), so now Tautulli is really the only true source of real history.. and I have history going back to 2016 lol |
@gold007eye If you hover over the percentage complete on that 08-29-2024 history item what does it say? I'm just wondering how close it is to your current watched percentage setting in Tautulli as they've got it at 75% complete currently (Tautulli split it up into 0/25/50/75/100 chunks in their API field watched_status, but they also have the exact percentage complete in percent_complete). The way I did the new rule logic it'll still consider 5-20-2023 the last viewed as it's not reached the watched percent that's configured yet. With the other rule I mentioned that we could create, I've got two trains of thought:
The panacea solution I originally thought about was being able set the percentage watched within the individual rules so you get a lot of flexibility, but the rules engine isn't setup for that currently. I'm thinking option number 2 would serve most use cases though and also be quite tidy from a user point of view? But technically speaking it is a workaround to a rules limitation and might not be the best implementation. Interested to here your thoughts here too @ydkmlt84 @jorenn92 |
I'm not entirely happy with the current state of the rule engine. It's still in the same form as when I first developed it, originally intended as a simple app for my personal use with only a handful of rules. I'd love to rewrite it into something more dynamic and flexible. A few days ago, I mentioned to @ydkmlt84 that I’d really like to add an 'addon' functionality. The idea is that users could simply drop zip files containing rules into a directory, and the system would load them. This way, anyone could add or modify rules without them being tied to the main repo or specific app versions. Of course, we could still provide some 'curated' battle-tested rules by default, but this approach would also allow users to integrate custom rules from others if they wish. That said, such a rewrite would be a significant change and is far outside the scope of this feature request. I just wanted to clarify that the rule engine doesn't have to remain in its current state forever. In my opinion, the best option, though the most work, would be to make it configurable within the rule itself. For example, we could add an extra UI field that appears when selecting a rule, similar to how custom values are handled now. However, as you pointed out, this would require changes to the rule engine, UI, YAML export/import, and community rule mechanisms. This might end up being too much work for the benefit it offers. I'm not sure how many users really need the ability to create two rules within the same ruleset based on different watch percentage statuses. If we go with option two, adding it as a general option, users can still create a second rule with a different percentage. TL;DR: While making the rule itself configurable is the best approach in my opinion, I don't think it's worth the effort for this particular case. Users can still work around the limitation by creating another rule with a different percentage when this becomes a general option. |
|
Appreciate the response, a rules rewrite sounds fun 😄 I'll have a look at making it a general option for now. |
Well, I probably won't have the time for it anytime soon, so who knows if it'll ever happen. |
|
By the way, in #1289 I altered the API command where the version info is fetched from. It was showing the Plex version before, because it fetched the Plex server info. |
@benscobie it is showing 72% complete. My guess is the last bit left is the credits. For my server I have the watched setting at 85% for movies and 90% for tv shows. This was just by me making adjustments to what overall worked for the past 10 years. As for the 2 options, I think that option 2 would work from a user perspective if you are able to either
all around these are going to be GREAT improvements in giving better accuracy in what the rules will pull in. |
On a side not of this. I would totally help coding if I had any clue on doing the coding.. lol. my career path has changed in the past decade so the last coding I worked on was visual basic. lol. I know this is a bit off topic, but I love the ability to export the "rules yaml" I think an improvement on that would be the ability to export the entire rule itself (e.g Title, Description, etc. more so for either 1) My entire setup is hosed and recreating everything would be very simple and/or 2) If I am doing testing sometimes it would be easier to just be able to duplicate an existing rule and change variables to see different outcome (for the sake of this topic. Taking a current rule that is based on Plex info and duplicate that with only needing to change the options from "plex" to Tautulli. |
|
@benscobie after doing some testing so far things are looking pretty good. All I needed to do was change I think your watched % idea is definitely going to come in handy with the new integration. So far this is all looking great and MUCH appreciated! Here is a good example of where that will help get things a little more accurate.
Current Plex code view times = 7 (as it is only calculating fully watched) New Tautulli code view times = 11 (as it is looking at total plays watch/partially watched) so being able to add that |
|
To add to this another example where that % watched getting added will be helpful with this. So this movie is looking at Tautulli times viewed as 2 based on api pull, but the actual % watched for these 2 views was 2% & 4% respectively so realistically you wouldn't want to count these as actual views because obviously this must have been a crappy movie :D
|
Currently a WIP to get some early feedback and to collect ideas on the type of rules you'd like to see. This currently implements seen by like Plex, but uses Tautulli's own watched logic.
Originally I was thinking the percentage watched could be controlled as part of the rule, but this doesn't seem possible the way the rule system works with lists? I'd want to do '[list] requested in Overseerr' contains '[list] watched in Tautulli' where watched percentage above 90.
Anyway, it turns out Tautulli already has it's own settings for this which controls the watched_status in their history response. I think this might be sufficient enough for most use cases?:
One improvement I'd like to make on this is to add some unit tests around the 'get' methods.
I made a couple of changes to settings.json:
typescript.preferences.importModuleSpecifier was set to non-relative but all imports actually use relative across the project.
typescript.enablePromptUseWorkspaceTsdk to prompt the user to switch to the workspace TS version.
I also noticed there's no default formatter specified so some of my formatting is different than the rest of the project. You're likely using Prettier given the extension recommendation and that Next.js ships with it? We could shove
"editor.defaultFormatter": "esbenp.prettier-vscode"in there as well.