[cmahlmann]

So I'm trying out Kodi 18 and I've run into a problem with ServerWMC. I have one machine setup as a back end running windows 7 and ServerWMC 1255. I have a different machine that I used to archive the recordings from the back end machine. I have a test bed front end that is running windows 10 and Kodi 18. I also have a living room machine that is running windows 10 and Kodi 17.6.

So here's the problem. The test bed front end will only play live-tv and recordings that are still on the back end machine. When I attempt to play recordings that have been moved to the archive machine I get a "PVR WMC Client Recording file not found" error. HOWEVER, I don't have this problem on the Living room machine. It can play Live TV and recordings from both the back end and archive machine without a problem from the living room machine. 

Here's the weird part. I'm running ServerWMC on the back end in service mode. When I take the back end out of service mode and run ServerWMC normally the test bed functions properly. It can access the files on the archive machine without a problem. I only have the problem when ServerWMC is in service mode. 

Any ideas what the problem could be or how to fix it?

Thanks!

[cmahlmann]

Here's the ServerWMC_Service.log

[krustyreturns]

Yeah, that's confusing alright.  I think the problem is probably due to differences in permissions between the two network shares and the kodi17 vs kodi18 thing is a red herring (i.e. if you changed each machine to the other's kodi version you'd still have the problem, proving the problem is locked to the machine).  And I think the difference between running as a service vs not is that the account swmc is running under changes between the two.  As support for this, in the posted swmc service log it tries to find this share using the network path that you set and it fails.  See here:

  2019/02/03 00:21:09.617 Additional watched 'Recorded TV' folders:
  2019/02/03 00:21:09.617 '\\CHAOSSERVER\Recorded TV' Error: folder not found

I bet when you run it not-as-a-service this check passes.  So check the permissions on your archive share.

[cmahlmann]

Thanks for taking a look. Yeah, a problem with permissions was my first thought too. So I checked.

I can access the archive share from both the test bed and the living room machine through the file browser without any problems. I also can access the the mapped drive from the back end without any issue. 

I restarted the service and then tried to play the "Bar Rescue" recording with "ChaosOffice2018" which is my test bed and it failed to play. I then went and turned on the living room machine "Media-PC" and tried to play the same "Bar Rescue" recording and it played just fine. Here's the log.  

 https://paste.kodi.tv/gatohepuvo

What I notice is that there doesn't seem to be any indication in the log that "Media-PC" went through the Serverwmc service at all to get to and play the "Bar Rescue" file.

I think you are right that it is a permissions problem between the back end service and the archive machine but why the difference in playback behavior between Kodi 17.6 "Media-PC" and the Kodi 18 "ChaosOffice 2018?
One seems to be going through ServerWMC and the other doesn't.  

I'm not sure how to give folder permissions to service on a remote machine. I'll dig around and see if I can't figure it out.

Any suggestions or ideas?

Thanks!

[cmahlmann]

Also, I'll try and put Kodi 18 on Media-PC but I won't be able to for at least a week.

[krustyreturns]

You see this difference because prior to Kodi18 finished recordings were accessed directly by kodi, pvr.wmc just provided a path to the recording file.  In this mode serverwmc would not know a recording was being played by kodi.  Kodi18 did away with this method of playback, so in kodi18 (and up I assume) finished recordings are accessed through pvr.wmc (like live-tv and active recordings are).  Because of this, serverwmc is now aware a finished recording is being played.

Imo there is no reason to do the kodi18 switch experiment unless you want to.