[Rouzax]

What I would like to be able to do is have multiple watched states for the different family members.
Lets say I watch a episode with my wife than after the episode I would like to get a pop up asking how viewed the episode

Something like this (obviously editable):

• Me
  
• Wife
  
• Everybody
  

Ideally this would be synced back to our trakt.tv accounts. This way we can both view episodes and filter to only show episodes that haven't been seen yet.

Right now we could kinda do it with profiles but that would require to switch profiles each time and even when we both view an episode it would require to register that watch state manual in the other profile.

[Karellen]

Moved to Feature Requests

[Kriven]

I'd like this as well, or at least profile integration for exporting playcount meta. Something like, in the video.nfo:

<user><name>MYNAME</name><playcount>1</playcount></user>

[Tyler Szabo]

It looks like this would require a schema change. Right now it appears that the "watched" status is determined by playCount > 0 in the files table. This makes some sense, especially if some behavior (also considering add-ons) relies on knowing how many times a particular file is played. But it does make more sense to associate the idea of "watched" with a particular title than with the file (especially when considering that files change; a stack may be merged into a single file - a better quality version in a new format may replace the old file) so either play count doesn't truly map to the files play count (as is the case when using an add-on like WatchedList - which is a fantastic add-on that's making this a lot easier for me, currently).

I propose adding 4 new tables. Firstly, episodewatched, moviewatched, and musicvideowatched which each maintain 2 foreign key references to the ID of the title and the ID of the watcher with a count. It's possible just to use those 3 and have a flat integer for profile ID; but to support the multi-device-with-MySQL option I'd opt to also maintain a watchers table that maps to a new profile property: watcher ID. This has 2 advantages - it enforces foreign key references (many benefits) and it'll allow for multiple devices to be provisioned with different user sets that might have different user IDs on the device (profile 0 on my laptop will be different from my wife's profile 0) but with that string in our profile Kodi can know which watched list to use.

Right now I've found the next best workaround is to just maintain 2 separate databases and use user different user accounts to separate the databases. It does mean that you have to manage your library twice, though. Also keep a backup with WatchedList - it'll maintain it's own database keyed on the IMdB ID and TheTVDB ID (which is also a good set of IDs to use - but I think Kodi should keep its world consistent with foreign keys and let 3rd parties figure out mapping to scraped data).

If anyone has links to other discussions about this, and especially the opinion of the dev team I'm interested in taking a crack at this for v19.

[Klojum]

Right now we could kinda do it with profiles but that would require to switch profiles each time and even when we both view an episode it would require to register that watch state manual in the other profile.

Yes... But how would this be different when using actual more than 1 user? Each person would still have to log out the current user, and log in him-/herself.

But yeah, having Kodi be multi-userfriendly would be a better situation. Unfortunately, we're not their yet.

If anyone has links to other discussions about this, and especially the opinion of the dev team I'm interested in taking a crack at this for v19.

There have been a couple of attempts to rewrite the Kodi databases, but for various reasons things stranded along the way. If you want to join in, get yourself acquainted with the Kodi code on Github.

[Tyler Szabo]

Thanks, I have a little bit of interaction with the codebase but not with a change of this scope. Since I'm new to contributing I want to get a better sense of the direction the core team wants to go and make sure I'm making the right change the right way. That's why it's important for me to know how the core team sees this feature; I'm willing to take a crack at it but I want to be respectful of the time.

As an example: If the multiple profiles is something to be deprecated then adding more support would be an anti-pattern and it might make more sense to focus on solving this problem a different way (for instance making a metadata caching service to make media library rebuilds go faster).

[Tyler Szabo]

I was thinking more about this after poking around (any change that affects the current way the playcount is reported will have some widespread side effects) and I realized that the "right" way to do this might be to acknowledge that this is something that an Add-On might want to manage. Refactor the default behavior to use the file's "playcount" metric but also provide the ability to use a plugin to determine the watched status and last position. That would also open up the opportunity to use 3rd party services to track the information.

[Spi-]

Hi,
I wanted to ask the exact same feature request so I'm leaving a comment for following.
Thanks to the dev!

[teriyaki]

History tells us that using add-on's as bandaids for what really should be in core functionality isn't a great solution because issues from that lack of core functionality get compounded and you can wind up with fragmented add-on spaghetti. The worse it gets, the more delicate the house of cards becomes and it always winds up one of two ways; A total mess that's a nightmare to maintain, or reaches a point where a core re-write/design correction is the lesser evil. The root problem here is Kodi's lack of true shared/multi-user support. Yes, there are profiles, which are no substitution for the real thing. They're very inconvenient too, for example, for people using Kodi in a family environment, especially with children, and who use their family tv instead of individual devices (pc/monitor, tablet, phone, etc).

I'm just suggesting that before investing in any more multi-user bandaids, consider if that's truly the best way to address current and future multi-user problems, or if it'd be wise to address the problem in the core once and for all in a consolidated & uniform way with the possibility of addons expanding on the core functionality. I don't know if there's a brainstorming thread on this topic but if not, perhaps there should be?