Posts: 20,237
Joined: Apr 2017
Reputation:
1,345
Moved to Feature Requests
Posts: 80
Joined: Nov 2017
Reputation:
2
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>
Posts: 3
Joined: Feb 2019
Reputation:
0
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.
Posts: 3
Joined: Feb 2019
Reputation:
0
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.
Posts: 1
Joined: Apr 2019
Reputation:
0
Hi,
I wanted to ask the exact same feature request so I'm leaving a comment for following.
Thanks to the dev!
Posts: 166
Joined: Dec 2017
Reputation:
12
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?