-
Notifications
You must be signed in to change notification settings - Fork 25
Fixing issue with episode matching, when titles match #117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Forgot to also say great work and thanks for putting this together. I've a few other pull requests I'm working on as well.
Not sure if I'll get them all done but these are the ones I'm looking at. If you want to accept them as pull requests great, if not I'll just build them for myself. |
|
Thank you so much for the contribution. I am very exciting for this project to get some work, there is much to improve. When it comes to matching, that is a hard thing to decide on. When I initially made the matching, I was unaware of the rating key function. In hindsight it is a much better matching technique for the media items. How ever, on the the main advantages of the janky title/string matching is that you can match media across of Tautulli libraries/instances. Meaning an episode of a show on Tautulli Server 1, will match with the same episode on another Tautulli server, Using rating key removes this feature (I guess the rating key is different?). It could still be worth it I suppose, I not sure what is the best approach here. |
|
Ah yes, I hadn't taken that into account. I did have a look and it looks like the RatingKey would definitely be different across libraries and Plex instances. I've looked at making it only use RatingKey when there are multiple tautulli instances configured. So I suppose it's a call on what should be considered the edge case? On a side note, I spotted a potential error on line 258 of statistics.go Shouldn't this be assigning to |
|
@aunefyren I've created a separate issue for tracking the issue I've pointed out above. Do you have any thoughts on whats the best approach for this pull request? |
|
@mcclown, sorry for the delayed response! Good point, if there is one Tautulli server, it should use rating keys. It can fall back to string matching when there are multiple instances. |
|
Ok, I've done more digging and I think I've found an identifier that is consistent across libraries and servers. It's the GUID that comes from Plex.
Some samples of episodes, that you might have, so we can validate they're consistent:
I'm working on a solution using these GUIDs instead of the other methods we've been trying. |
|
Ok, I've made the changes required to match on the GUID that Plex returns for episodes. I've tested that
If someone else wants to verify that they get the same GUIDs as me, for a specific episode, on another server, that should close that out. It might be worth looking at moving all other matching over to using this GUID as well but I haven't made that change, as there's no bug there. Also, I've left the previous matching logic as a fallback...but as I said above, the GUID always seems to be present, so this could probably also be cleaned up. |
|
This seems like a much better approach! Based on some research that GUID is generated by Plex for their metadata agent, which aggregates from different sources like TVDB, TMDB and such. It is probably why they can have shared watch history across from Plex servers. In theory you could be using another agent on your server, but I am not sure we can accommodate for that. It seems like that simplest approach to correlate media items accross Tautulli tenants. |
|
Yes, I should have said that. It will work as long as the metadata agent is the same across servers...and agreed, that's going about as far as we reasonably can to try to match. |
So if episodes are watched before a title is available, then they appear in the Tautulli watch history as TBA. The previous matching algorithm relied on episode title and would lead to the most liked episode being misidentified.
I've updated the logic to use the RatingKey, if available, which should be a unique value for an episode. We still fallback to the previous method, if the RatingKey is missing.