[scarecrow420]

You could also check in WMC itself whether the recording is flagged "Watched" or not

How do I check that? I tried looking at the properties of the WTV file (nothing) and in WMC itself, but the only thing I see in WMC is that I can resume playback, but it doesn't make it easy for me to see what's watched or not.

No idea! I just know that the WMC API has a "watched" flag and I am setting that true/false accordingly. I actually was not very much of a WMC user I have to admit! I assumed it must say somewhere in the recordings list if it was watched or not. Anyhow, I think you've proven that it's persisting correctly in the backend/WMC just that XBMC doesnt refresh the list automatically, and I forgot to issue the manual recording refresh request...

Actually, looks like I didn't trigger the recording list refresh on XBMC after making the SetPlayCount() call. You'd think it would automatically refresh the recording list but it doesn't, we have to explicitly rtigger it. And it looks like I missed that part. Dang it. Im assuming if you close XBMC and open it again (or use another client) the watched status should be OK, it's just the client where you performed the action where it isn't being refreshed immediately?

Here's what happens when I say MARK WATCHED (which works fine):
2014/07/14 19:43:49.983 Received client request: MY-PC|GetResumePosition|10977524113473053
2014/07/14 19:43:49.992 Finished request GetResumePosition in 0.01s
2014/07/14 19:43:51.822 Received client request: MY-PC|SetPlayCount|10977524113473053|1
2014/07/14 19:43:51.830 Finished request SetPlayCount in 0.01s
2014/07/14 19:43:51.831 Received client request: MY-PC|SetResumePosition|10977524113473053|0
2014/07/14 19:43:51.838 Finished request SetResumePosition in 0.01s
2014/07/14 19:43:51.840 Received client request: MY-PC|GetRecordings
2014/07/14 19:43:51.852 Finished request GetRecordings in 0.01s

And here's what happens when I say MARK UNWATCHED (which doesn't refresh the UI and requires me to reboot to see the unwatched status):
2014/07/14 19:45:04.022 Received client request: MY-PC|GetResumePosition|10977524113473053
2014/07/14 19:45:04.027 Finished request GetResumePosition in 0.01s
2014/07/14 19:45:05.327 Received client request: MY-PC|SetPlayCount|10977524113473053|0
2014/07/14 19:45:05.333 Finished request SetPlayCount in 0.01s

So in the UNWATCHED example, you're right, it's not calling GetRecordings again after SetPlayCount.

And you're also right... when I close out of XBMC and then open it again, the watched status is correct (meaning, for an item that I just marked unwatched, it is now showing up as unwatched).

The reason why the first one works is because we trigger a manual Recordings refresh after XBMC calls SetResumePosition (which in the case of marking an item as Watched, seems to just so happens to be AFTER the SetPlayCount call). So essentially you are only getting a recordings refresh when setting an item as watched, because XBMC also set the resume position.

When marking as unwatchd it seems it doesnt SetResumePosition, only SetPlayCount and as I already mentioned I forgot/didnt realise that I needed to explicitly trigger a recordings list refresh from SetPlayCount. In both cases (ResumePosition and PlayCount/WatchedSTatus) you would assume that XBMC should refresh the recordings list itself since it just changed the state of something and registered that with the backend ,but we found when implementing the ResumePosition that we had to manually trigger the list update to actually reflect the change XBMC just made, and clearly that workaround is also required for MarkWatched/Unwatched.

I already made the fix to this this morning but we will need to build a new pvr.wmc addon version 2.99 to include that fix. And before going around that merry go round again, I probably need to test it to make sure it actually works properly this time!