[LehighBri]

As posted on the MB3 forums, I have Windows 7 64-bit and ServerWMC v1150 on Gotham 13.1. I have a couple issues related to watched status not being synced.

When I watch a show in XBMC, on my one client, I see the episode is marked as watched, but then when I open another client (both are rpi's), it is showing the episode as not watched.

Thoughts on this? Isn't the watched status supposed to be in sync across everything (all XBMC clients, etc)? And if so, is it a "real-time" sync or is there some delay? This is a big use case for me as I have several clients and would like to make sure the WMC recordings status is always in sync.

[scarecrow420]

The backend stores/retrieves resume info provided by XBMC when the client stops watching a recording. When one client sets resume info, we set a flag in the server that tells each client to refresh their recording list/info on the next status poll (clients send status poll to the server at least every few minutes but often more frequently when you are actively using them and going between Timer/Recording/EPG screens, watching live channels etc)

But there isn't anything explicitly in the XBMC PVR API regarding watched status. Unless XBMC "infers" watched status by using a resume state of "close to the end of the program" to indicate it's been watched. I sort of doubt it does this.

Ive noticed on my setup that watched status for recordings DOES seem to sync between cilents, but it doesnt happen instantly.

I think that XBMC stores this stuff in the videos database and since I used a shared MySQL database for the music/video libraries, that means this info is synched between clients. But it's not instant.

What is your setup? are you running with shared MySQL database? Do your watched status NEVER sync or just not sync immediately?

Also can you tell me if you have a client running on same server as ServerWMC or only remote clients? Reason I ask is that if XBMC stores watched status according to file path, we give a local client the local path and a remote client the smb:// path which would mean they are 2 separate entries in XBMC database. This doesnt matter for resume info, since that is explicitly handled through calls t othe PVR backend but it would affect watched status I think. I have long thought we should provide consistent smb:// paths to all clients local and remote, however that does meant that simple users with basic setups (local client only) need to configure shares and permissions which is a higher barrier of entry to getting ServerWMC up and running, and one of the good things about ServerWMC is how easily you can get it going for the simple use case...

In regards to MB3 I dont know specifically how it does things but considering it has one server but multiple clients, assumedly all MB3 clients will already be aware that the recording is watched if that occured within MB3... so presumably you are just talking about sharing that information between XBMC and MB3. We can certainly add a new backend call to set/get watched status and can persist that just as we do the resume position however until XBMC was changed to call this (slow development cycle and reasonably unlikely to be done IMO) you still wouldn't get the information flowing into/out of XBMC. MB3 could possibly infer the episode is watched in XBMC if the stored resume position is close to the end of the file... But that still doesnt help with XBMC knowing what occured on the MB3 side

[scarecrow420]

So I've just been perusing the XBMC code and I actually found that the XBMC PVR API DOES have a function call for storing watched status in the backend! It is confusingly called RecordingsPlayCount but essentially a play count of more than 0 would mean it's been watched. We don't currently support this XBMC PVR capability in our addon (not sure why we missed it) but we can add support for it in the next version of pvr.wmc and ServerWMC to store the playcount in the backend and provide it as a field on the recording items that are sent when requested (and refreshed on other clients via the next status poll, when one client makes a change). MB3 could then also call the new message in ServerWMC if they want

[LehighBri]

So I've just been perusing the XBMC code and I actually found that the XBMC PVR API DOES have a function call for storing watched status in the backend! It is confusingly called RecordingsPlayCount but essentially a play count of more than 0 would mean it's been watched. We don't currently support this XBMC PVR capability in our addon (not sure why we missed it) but we can add support for it in the next version of pvr.wmc and ServerWMC (and then MB3 can also call it if they want)

Fantastic! And I'll respond to your other post shortly, but adding that enhancement would be great.

---

What is your setup? are you running with shared MySQL database? Do your watched status NEVER sync or just not sync immediately?

Also can you tell me if you have a client running on same server as ServerWMC or only remote clients? Reason I ask is that if XBMC stores watched status according to file path, we give a local client the local path and a remote client the smb:// path which would mean they are 2 separate entries in XBMC database. This doesnt matter for resume info, since that is explicitly handled through calls t othe PVR backend but it would affect watched status I think. I have long thought we should provide consistent smb:// paths to all clients local and remote, however that does meant that simple users with basic setups (local client only) need to configure shares and permissions which is a higher barrier of entry to getting ServerWMC up and running, and one of the good things about ServerWMC is how easily you can get it going for the simple use case...

I am not using a shared database. I have a windows client (which is also my MB3 server and ServerWMC server) running Gotham 13.1, and I have 3 Rpi's running OpenELEC 4.0.7 which is based on Gotham 13.1 too. It seems to NEVER sync across any of those clients.

In regards to MB3 I dont know specifically how it does things but considering it has one server but multiple clients, assumedly all MB3 clients will already be aware that the recording is watched if that occured within MB3... so presumably you are just talking about sharing that information between XBMC and MB3. We can certainly add a new backend call to set/get watched status and can persist that just as we do the resume position however until XBMC was changed to call this (slow development cycle and reasonably unlikely to be done IMO) you still wouldn't get the information flowing into/out of XBMC. MB3 could possibly infer the episode is watched in XBMC if the stored resume position is close to the end of the file... But that still doesnt help with XBMC knowing what occured on the MB3 side

I have just recently started using MB3 and am all in... it's fantastic (I've used Plex in the past and love the idea of having a central server that services all my need... but I like XBMC better than Plex due to live tv, comskip, etc). So... ideally... to me, it shouldn't matter where I indicate a show is watched... it should keep everything in sync back to WMC (e.g. if I watch a show in MB3, it should update WMC... if I watch a show in WMC, it should update MB3, etc)

[scarecrow420]

Ive confirmed that the "sync" of recordings watched status on my system comes from the shared video library database. So it seems this is responsible for syncing the watched status between my clients. It has delays though, and when one client watches something, that isn't immediately refreshed on other clients etc.

But as I mentioned I will add support for storing the "PlayCount" in the backend (as well as setting the Watched flag in WMC when playcount is >0) so both XBMC and MB3 can sync this info (assuming MB3 implement their side).


As an aside, how come you have multiple XBMC clients but are not sharing your music/video databases? Do you only use XBMC for live TV and MB3 for everything else? If you use XBMC for any other video/music I would urge you to setup a shared database (install MySQL on your "server" box). That way all the metadata scraping and scanning items into the library only has to happen once, and all clients can share that library metadata plus resume position and watched status of videos, music etc.

[LehighBri]

Ive confirmed that the "sync" of recordings watched status on my system comes from the shared video library database. So it seems this is responsible for syncing the watched status between my clients. It has delays though, and when one client watches something, that isn't immediately refreshed on other clients etc.

But as I mentioned I will add support for storing the "PlayCount" in the backend (as well as setting the Watched flag in WMC when playcount is >0) so both XBMC and MB3 can sync this info (assuming MB3 implement their side).

Great, thanks. Looking forward to trying it out!

As an aside, how come you have multiple XBMC clients but are not sharing your music/video databases? Do you only use XBMC for live TV and MB3 for everything else? If you use XBMC for any other video/music I would urge you to setup a shared database (install MySQL on your "server" box). That way all the metadata scraping and scanning items into the library only has to happen once, and all clients can share that library metadata plus resume position and watched status of videos, music etc.

You're right, I only use XBMC for live tv and MB3 for everything else. I used to use UPNP to keep watched status in sync, but it was also fluky. And live tv recordings watched status is different than the UPNP model. I think the point of all of this is to use things like MB3 and UPNP to get away from the whole shared database idea.

[krustyreturns]

Good catch scarecrow (yeah, not sure who we missed it). Currently there is no way to get the 'watched' status into mb3 but they plan to address it.

[LehighBri]

I see that a newer version of the server and clients are available that now support this (thanks!). Just so I'm clear, is the watched and resume status ultimately being synced back to WMC itself? I would think that WMC should be the ultimate source for watched and resume status, and serverwmc is more of a gateway between the various clients and WMC in terms of storing/syncing/etc the status. Or is another approach being taken where serverwmc only stores the watched/resume status and it doesn't get synced back to WMC? I probably don't care either way, just curious on how it works. Great work!

[scarecrow420]

It's stored in WMC itself WMC has a "watched" flag which is Boolean (true/false) whilst XBMC has a "PlayedCount" integer value. So what Im actually doing is setting the Watched status in WMC when PlayedCount > 0 but also storing the actual integer value in WMC as a Bookmark (essentially a timestamp but can be abused to store any numerical value) which means we can honour/preserve the PlayedCount that XBMC is providing. But yes it also has the "benefit" that if you did use WMC natively for whatever reason, recordings you watched in XBMC should also show up as watched in WMC. Note that I didn't do a whole lot of testing on this as I just quickly put it together on the weekend based on this forum request, so please let me know if it's working for you! You need to update the client to 0.2.98 as well, to enable this feature

btw you're pretty keen eyed to discover there is a new version released when it hasn't been officially announced yet... Would I be correct in assuming the automatic "Check for Updates" function is how you found out? Im dying to know how the check/apply updates stuff is going for people as it was only added in build 1150 so this new build 1154 is the first time it's been used in the wild

[LehighBri]

It's stored in WMC itself WMC has a "watched" flag which is Boolean (true/false) whilst XBMC has a "PlayedCount" integer value. So what Im actually doing is setting the Watched status in WMC when PlayedCount > 0 but also storing the actual integer value in WMC as a Bookmark (essentially a timestamp but can be abused to store any numerical value) which means we can honour/preserve the PlayedCount that XBMC is providing. But yes it also has the "benefit" that if you did use WMC natively for whatever reason, recordings you watched in XBMC should also show up as watched in WMC. Note that I didn't do a whole lot of testing on this as I just quickly put it together on the weekend based on this forum request, so please let me know if it's working for you! You need to update the client to 0.2.98 as well, to enable this feature

btw you're pretty keen eyed to discover there is a new version released when it hasn't been officially announced yet... Would I be correct in assuming the automatic "Check for Updates" function is how you found out? Im dying to know how the check/apply updates stuff is going for people as it was only added in build 1150 so this new build 1154 is the first time it's been used in the wild

Great explanation... thanks! And you're right, I rebooted my server today and happened to open serverwmc where I saw the Update tab turn red. I went there it and it said there was an update available so looks like that feature works (and the update installed and was applied with no issues... worked great....)! One quick question. I see the updated Windows client is out... any thoughts on when the updated RPi client will be out? My clients are mostly RPi's so looking forward to testing that out.

[scarecrow420]

Oh yeah, sorry I forgot your clients were RPI

Yeah typically krusty releases the windows addon, I do the android addons when I can dust off my memory banks on how to actually do all that stuff on the Ubuntu VM I have setup for the purpose! We have some other helpers who produce the IOS/OSX builds for us as well.

But with the RPI client addon, we most recently (for 0.2.95) had lifted it out of "miappa's" RaspBMC builds (with permission). So you might try seeing if anyone over there can do a build to include 2.98
http://forum.xbmc.org/showthread.php?tid=176043&page=34

Hmm, reading that thread it seems like miappa is on holidays for the summer!

Not being an rpi user (well I have one I just don't use it for XBMC and haven't been bothered to set it up etc!) I don't know if anybody else does similar builds for rpi? As of today, the pvr.wmc 2.98 changes were pulled into the official github repo for xbmc-pvr-addons so anyone interested just needs to build the "master" branch of the official pvr-addon repo

[LehighBri]

Oh yeah, sorry I forgot your clients were RPI

Yeah typically krusty releases the windows addon, I do the android addons when I can dust off my memory banks on how to actually do all that stuff on the Ubuntu VM I have setup for the purpose! We have some other helpers who produce the IOS/OSX builds for us as well.

But with the RPI client addon, we most recently (for 0.2.95) had lifted it out of "miappa's" RaspBMC builds (with permission). So you might try seeing if anyone over there can do a build to include 2.98
http://forum.xbmc.org/showthread.php?tid=176043&page=34

Hmm, reading that thread it seems like miappa is on holidays for the summer!

Not being an rpi user (well I have one I just don't use it for XBMC and haven't been bothered to set it up etc!) I don't know if anybody else does similar builds for rpi? As of today, the pvr.wmc 2.98 changes were pulled into the official github repo for xbmc-pvr-addons so anyone interested just needs to build the "master" branch of the official pvr-addon repo

Great, thanks. I just posted in the OpenELEC and Raspbmc threads to see if anyone can help. Will see what happens.

[LehighBri]

Quick I update. I'm running the latest server (1154) with the latest client on my Windows Gotham clients (0.2.98) and noticed a small issue. When I mark a show as watched, it works great and syncs just fine across my Windows clients. But I just encountered a situation where I accidentally marked a show as watched (that I hadn't watched before), and when I go to mark it as unwatched, nothing happens . Nothing happens in the XBMC UI, and nothing is "cleared" or reset on the server (normally when I mark a show as watched, the XBMC UI updated immediately to indicate that that the show was watched). Thoughts on this?

Here's what I see in the serverwmc.log. Not sure if this helps, but is a start:
2014/07/14 14:50:23.410 Received client request: MW7R0FYG2ZJQ6T|GetResumePosition|10977524115596572
2014/07/14 14:50:23.422 Finished request GetResumePosition in 0.01s
2014/07/14 14:50:24.883 Received client request: MW7R0FYG2ZJQ6T|SetPlayCount|10977524115596572|0
2014/07/14 14:50:24.896 Finished request SetPlayCount in 0.01s

[scarecrow420]

The SetPlayCount call is sending through a value of 0 (expected) and in the backend that should be setting the Watched status in WMC to False and the bookmark to 0:00:00. Then XBMC client should request recordings list again and the recording should come back with a playcount of 0. Do you see a "GetRecordings" request immediately after that SetPlayCount one? If you go into your config.xml and add GetRecordings to the "LogRequestFull" tag, eg

change <LogRequestFull /> to
<LogRequestFull>GetRecordings</LogRequestFull>

Then restart ServerWMC or hit Reload Config on the Debug tab, then it will log the message replies for GetRecordings request and we can see what the value of PlayedCount being sent back on that recording item is


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

---

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?

[LehighBri]

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.

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).