2014-07-10, 04:53
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
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
