Trakt for MP2 (1 Viewer)

[aspik]

the play count is handled server side here.

But this method also doesn't have a play count parameter. The value is read from the DB and always incremented. How can I know if a MI is unwatched (or set it as unwatched) as the play count is every time increased.

I can understand that a play count attribute can be useful in some cases, but if it's never gets reseted it can't be used to know the watched state.

My guess is you are not reloading the user data after changing the play count?

Not that I know, could you please point me to an example? I see that each time I restart the client the play count is the "real" one.

As you can see there is a little "cheat" for KEY_PLAY_PERCENTAGE to avoid reloading the user data by just changing the values in the already loaded user data.

Yes, I noticed. Does reloading the user data have such a performance impact? Or are they other reasons why it' can't be reloaded each time the watched action is called?

 

[henso]

I can understand that a play count attribute can be useful in some cases, but if it's never gets reseted it can't be used to know the watched state.

Actually now thinking about it, the play count should never be reset, because it is used to show the most played media items. Just because you reset the play state doesn't mean you never watched. The KEY_PLAY_PERCENTAGE is used for showing the current play state. You should use that. If it is 0 or missing, it is un-watched and if it is 100 it is watched. That's how the client does it. What you want to do with the values in between is up to you.

Not that I know, could you please point me to an example?

You just load the media items again with a user id and then the data will be added to the media item data.

Yes, I noticed. Does reloading the user data have such a performance impact?

I don't know much about the client innards but you would have reload only that media item, once the data returns you would have to find and update the media item in the list and lastly you would have to update the whole view because I don't think updating a single list item is currently possible. Updating the list would currently mean it would jump to the top of the list forgetting the previously focused media item IIRC. And really I don't think it is that necessary because the client data is not constantly synced with the server anyway, so there is no guarantee that the data is ever up to date.

 

[aspik]

The KEY_PLAY_PERCENTAGE is used for showing the current play state. You should use that. If it is 0 or missing, it is un-watched and if it is 100 it is watched. That's how the client does it. What you want to do with the values in between is up to you

IMHO this isn't a reliable way to know if something is watched or not. There is a setting "watched play percentage" and each client/user can have a different value to mark a MI as watched. I agree, that its enough for the the watched state in UI, but marking a video as watched or unwatched in the library shouldn't be done via the play percentage attribute. Can't we have a simple "IsWatched" boolean in DB?

 

[henso]

Can't we have a simple "IsWatched" boolean in DB?

For the media item itself or the user data?
If for the item what should it be set to if some users watched it while others have not?
If for the user data, I don't see this as more reliable as the KEY_PLAY_PERCENTAGE data.
I'm not sure, I understand the problem. Could you provide an example?
Sorry, just trying to understand the issue.

 

[Lehmden]

Could you provide an example?

One user has set "watched" to 80%, the other has set it to 99%. Imagine the file is played for 87% and one user has it as watched while the other has it as partially watched. So for syncing with trakt the plugin also needs to read the user settings (to decide if it is watched or not) that are not even stored in the database afaik...

Edit
The value is not even stored on the MP2 server at all, it's stored in Client configuration (MediaPortal.UI.Services.Players.Settings.PlayerManagerSettings.xml)...

 

[henso]

One user has set "watched" to 80%, the other has set it to 99%.

IIRC this doesn't matter because once the watch percentage is above the clients threshold on the client, it will set it as 100% when playback ends, and update the database.

 

[henso]

IMHO this isn't a reliable way to know if something is watched or not. There is a setting "watched play percentage" and each client/user can have a different value to mark a MI as watched.

Sorry, now I understand what your issue is after reading @Lehmden post. As you might have read from my post, you can safely assume that if a client considers a media item as watched, it will save the play percentage as 100%, no matter what the actual watch percentage was.

 

[aspik]

I was away...

For the media item itself or the user data?

Since we have user management now, a watched state outside user data doesn't make any sens anymore

So for syncing with trakt the plugin also needs to read the user settings (to decide if it is watched or not) that are not even stored in the database afaik...

Knowing this settings is not a problem, trakt is running within the client and I'm already reading the user settings. So this would be a matter of reading the watched played percentage setting and comparing with the value from MI. I was more afraid because such a setting exists. The user could have for same time the default value, and later decide to change it. I thought that after changing the value and syncing the library again, an already watched movie could be read as unwatched.

As you might have read from my post, you can safely assume that if a client considers a media item as watched, it will save the play percentage as 100%, no matter what the actual watch percentage was.

OK, good. Then to know if a MI is watched I'll read the play percentage attribute, but for marking it as watched/unwatched I still use the watched actions as this way it will be saved to the DB.

 

[henso]

Then to know if a MI is watched I'll read the play percentage attribute

Great.

for marking it as watched/unwatched I still use the watched action

That would be smart. If we change/update it, you would not have to change anything.

 

[aspik]

and it again synced every episode as watched (on trakt), as of today, at 13:13, the time of the initial sync.

found the reason for this issue. To build the JSON body with the collected episodes I'm using helper (build) methods from the TraktApiSharp library. I was wrongly using the collectedAt date from the show instead of collectedAt from the episode. This way every episode was posted to Trakt with missing collectedAt date and Trakt.tv displayed them with the sync date.

The problem is, that TraktApiSharp in the current implementation only allows to post single episodes with collectedAt dates which have valid IDs (tvdb, tmbd, etc.). The episode IDs are not the same as the show IDs. Of course we don't have this kind information in our database (and there is no need to have it).

I already contacted the author of the Trakt lib and he admitted, that his implementation is only based on the examples available in the Trakt API documentation. Those examples are very basic and don't show all possible combinations.
The same applies for posting watched episodes. TraktApiSharp (or Trakt.NET as it has been recently renamed) doesn't allow to post single episodes + watchedAt without valid episode IDs.

In agreement with the author I raised tickets for this two missing features and he promised to add it in the upcoming version.

@Alberto83
Movies don't have this limitation and I fixed the watched/unwatched issues. If you like, I can post tonight a version where syncing series is disabled and you can test the movies part. Or you can wait until a new Trakt.NET lib comes out and test it then.