2014-07-31, 04:24
OK so there is no need for "remux all recordings" in normal operation anymore? Only as a troubleshooting step... Thanks Dilligaf
2014-08-02, 06:24
(2014-07-31, 01:36)krustyreturns Wrote: Ok. I tried to setup what you are describing and I can't get it to fail. Try setting the flag Debug_LogGetRecordings to true in the config.xml file. Then next item the items vanish on you, post a link to the serverlog. Actually maybe just restart serverwmc and post the startup log now just so we can see how you have it configured.
OK - have enabled debugging, and here's my log after starting up swmc. I'll post the next log once I have the issue...
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
2014-08-05, 11:03
OK here's a link to a log file when there was an issue. only some of the recordings disappeared. let me be clear - some of the recording that disappeared, are sitting on my server (unc share), however, it was NOT ALL OF THEM. some of the recordings sitting on the server were still visible, and some weren't. again, restarting swmc fixed the problem...
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
2014-08-05, 20:19
Most of the getrecordings calls return 0 files according to the second log, unfortunately there isn't much of a clue as to why this is happening. Also in the first log it says:
2014/08/02 13:16:28.230 Additional watched 'Recorded TV' folders:
2014/08/02 13:16:28.234 '\\SERVER\Recorded TV' ShareStatus: Warning, Folder is not share with everybody or homegroup.
So at startup anyway swmc seems to think the server's recorded tv folder is not shared with everybody. But since restarting swmc seems to make everything okay, this just adds to the confusion.
Your transfer script runs every two hours right? Any idea how long it takes to transfer one wtv file over your network?
2014/08/02 13:16:28.230 Additional watched 'Recorded TV' folders:
2014/08/02 13:16:28.234 '\\SERVER\Recorded TV' ShareStatus: Warning, Folder is not share with everybody or homegroup.
So at startup anyway swmc seems to think the server's recorded tv folder is not shared with everybody. But since restarting swmc seems to make everything okay, this just adds to the confusion.
Your transfer script runs every two hours right? Any idea how long it takes to transfer one wtv file over your network?
2014-08-06, 03:36
What I noticed was sometimes GetRecordings takes 20 seconds and others (most of the time) it takes 0 seconds. Presumably the latter is when you lose recordings but im surprised by the time taken of the earlier call as well though...
I think if you turn on full response logging for the "GetRecordings" message, we will be able see exactly what is sent back to the client each time it asks, so we can see how many/what recordings are sent back normally and then when some go missing we can see exactly which ones they were etc.
To do this, edit the config file and add GetRecordings to the LogRequestFull section
eg change
to
I think if you turn on full response logging for the "GetRecordings" message, we will be able see exactly what is sent back to the client each time it asks, so we can see how many/what recordings are sent back normally and then when some go missing we can see exactly which ones they were etc.
To do this, edit the config file and add GetRecordings to the LogRequestFull section
eg change
Code:
<LogRequestFull />Code:
<LogRequestFull>GetRecordings</LogRequestFull>
2014-08-06, 10:44
Ok will do, and I'll post the log file back here when it happens again. Thanks guys!
(In terms of how long it takes to transfer the files, each recording only takes a minute to transfer - it does depend on how big the recording is!)
(In terms of how long it takes to transfer the files, each recording only takes a minute to transfer - it does depend on how big the recording is!)
2014-08-06, 21:26
I don't want to change too many variables, but when you get time try this experiment also: in the config.xml file change this flag:
<UseRecLibraryWatcher>false</UseRecLibraryWatcher>
then save the config and restart serverwmc. See if you still get the strange behavior when files are moved.
<UseRecLibraryWatcher>false</UseRecLibraryWatcher>
then save the config and restart serverwmc. See if you still get the strange behavior when files are moved.
2014-08-07, 12:37
ok here we go
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
You can see how it gets 23 entries initially. when the machine wakes up in the afternoon though, it can only see 2 or so.
krusty - i hadn't made that change to the config file when i did this last log, but i've just made the change now - will let you know in a couple of days if it fixes the problem!
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
You can see how it gets 23 entries initially. when the machine wakes up in the afternoon though, it can only see 2 or so.
krusty - i hadn't made that change to the config file when i did this last log, but i've just made the change now - will let you know in a couple of days if it fixes the problem!
2014-08-08, 02:34
Ive had a look through the log and found that in normal circumstances the call should be pretty much instant and found 22 recordings
after waking from sleep the call took 19 seconds and only found 1 recording. Is it possible the 1 recording it found is locally on the C drive, and all the missing ones are on the share?
Because you have set Debug_RequestAllRecordings to true, we cant see the actual file paths of the recordings in the GetRecordings call. Normally we send the path over in the GetRecordings response, and XBMC client can just access the recordings directly but that debug option causes the path to be passed over as blank so XBMC has to request the recording file name from the server when it actually wants to play it back. This helped with setups where files are moved from 1 place to another (eg archiving recordings) but in this troubleshooting case it would be nice to see the paths being returned so we could see if the missing recordings are on the server and the recordings that don't go missing are on local drive still. So if you could turn off that debug option for a while, we could get more data in the logs
Anyhow, it seems to me like a problem where the HTPC (or at least WMC recordings watcher/library) cant see the remote share anymore after waking from sleep. Not sure why restarting ServerWMC seems to get it working again, all ServerWMC does is taps into WMC's recording library and it's WMC that is actually providing back the list of recordings. Perhaps when ServerWMC starts up it kicks the recordings library into shape and it can get everything properl;y again. It might be possible for us to try and do something if we notice the machine has woken up from sleep or something like that. difficult to debug though!
After waking up from sleep can you access the \\SERVER share ok in windows explorer?
Also since ServerWMC complains about the \\SERVER\ share not being shared properly it would be an interesting idae to see if that's related. clearly everything is working anyhow, using windows security and i assume probably the same user/password on HTPC and SERVER, but you could also specify the user/password in ServerWMC settings and also double check the share permissions on the SERVER share, ideally it would be good to not see ServerWMC complain about the SERVER share as it starts up
after waking from sleep the call took 19 seconds and only found 1 recording. Is it possible the 1 recording it found is locally on the C drive, and all the missing ones are on the share?
Because you have set Debug_RequestAllRecordings to true, we cant see the actual file paths of the recordings in the GetRecordings call. Normally we send the path over in the GetRecordings response, and XBMC client can just access the recordings directly but that debug option causes the path to be passed over as blank so XBMC has to request the recording file name from the server when it actually wants to play it back. This helped with setups where files are moved from 1 place to another (eg archiving recordings) but in this troubleshooting case it would be nice to see the paths being returned so we could see if the missing recordings are on the server and the recordings that don't go missing are on local drive still. So if you could turn off that debug option for a while, we could get more data in the logs
Anyhow, it seems to me like a problem where the HTPC (or at least WMC recordings watcher/library) cant see the remote share anymore after waking from sleep. Not sure why restarting ServerWMC seems to get it working again, all ServerWMC does is taps into WMC's recording library and it's WMC that is actually providing back the list of recordings. Perhaps when ServerWMC starts up it kicks the recordings library into shape and it can get everything properl;y again. It might be possible for us to try and do something if we notice the machine has woken up from sleep or something like that. difficult to debug though!
After waking up from sleep can you access the \\SERVER share ok in windows explorer?
Also since ServerWMC complains about the \\SERVER\ share not being shared properly it would be an interesting idae to see if that's related. clearly everything is working anyhow, using windows security and i assume probably the same user/password on HTPC and SERVER, but you could also specify the user/password in ServerWMC settings and also double check the share permissions on the SERVER share, ideally it would be good to not see ServerWMC complain about the SERVER share as it starts up
2014-08-09, 00:40
You are right - the one recording it can see is the one that's still on the C drive.
One thing I have not told you (didn't think it was really relevant at the time) is that often when xbmc appears after waking, it says 'waiting for LAN.. 192.168.1.2' (which is the SERVER IP), and the timer ticks down about 5 secs. This would be because my xbmc database is shared on the SERVER machine (so other machines in the house can share the library etc).
I'm not sure if it's the HTPC network card waking up or windows (probably the latter), but by the time I check any SERVER shares, the network connection is established and all is fine.
So, my assumption here is that swmc is checking the server share immediately after waking up and doesn't see anything. Does swmc not check a 'failed' share again? Or is this possibly xbmc (and wmc.pvr) saying that there's no recorded tv on those shares, and don't bother checking again?
In any case, I'll set Debug_RequestAllRecordings to false and see what happens!
One thing I have not told you (didn't think it was really relevant at the time) is that often when xbmc appears after waking, it says 'waiting for LAN.. 192.168.1.2' (which is the SERVER IP), and the timer ticks down about 5 secs. This would be because my xbmc database is shared on the SERVER machine (so other machines in the house can share the library etc).
I'm not sure if it's the HTPC network card waking up or windows (probably the latter), but by the time I check any SERVER shares, the network connection is established and all is fine.
So, my assumption here is that swmc is checking the server share immediately after waking up and doesn't see anything. Does swmc not check a 'failed' share again? Or is this possibly xbmc (and wmc.pvr) saying that there's no recorded tv on those shares, and don't bother checking again?
In any case, I'll set Debug_RequestAllRecordings to false and see what happens!
2014-08-10, 01:05
Hi guys - here's the log file with Debug_RequestAllRecordings set to false.
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
https://drive.google.com/file/d/0B-ajbAz...sp=sharing
2014-08-10, 11:41
Hmm well that log shows no recordings were sent back. It also shows an error where it couldnt resolve "googledrive.com" which is our atuoupdate check location. It seems clear that the PC does not have network access as it is coming out of this sleep state and this must be to blame for the recordings failing to be retrieved.
The thing is, ServerWMC doesnt do any of this, we just ask WMC for a list of recordings. Infact everytime a XBMC client asks for recordings, we go to WMC library and grab the list of recordings "live" we don't do any caching of these in ServerWMC. So not only does WMC not see any of the \\SERVER recordings when the machine wakes up from sleep, it also seems to never see them again, until ServerWMC is restarted. This must do something to kick start WMC recordings library into action again. How do things look in WMC itself? If you have WMC open on the menu then put the computer to sleep and wake it up then go into recordings in WMC, are the items there or missing?
Also can you reproduce this even by just putting the PC to sleep and then waking it up straight away or does it have to be asleep for a longer amount of time?
The thing is, ServerWMC doesnt do any of this, we just ask WMC for a list of recordings. Infact everytime a XBMC client asks for recordings, we go to WMC library and grab the list of recordings "live" we don't do any caching of these in ServerWMC. So not only does WMC not see any of the \\SERVER recordings when the machine wakes up from sleep, it also seems to never see them again, until ServerWMC is restarted. This must do something to kick start WMC recordings library into action again. How do things look in WMC itself? If you have WMC open on the menu then put the computer to sleep and wake it up then go into recordings in WMC, are the items there or missing?
Also can you reproduce this even by just putting the PC to sleep and then waking it up straight away or does it have to be asleep for a longer amount of time?
2014-08-10, 11:43
Yeah that's the thing - when I look in WMC, i can see all the recordings. I will double-check though. I'll check on the sleep length too. Thanks again!
2014-09-06, 01:52
Apologies it's been a while - was moving house. I've now overcome any possible WOL issue, as the windows machine now never goes to sleep.
I can confirm however, that after a couple of days, recordings do disappear - but they're not strictly all the ones on the network share. It can be only some of them. The most important thing, I think, is:
When I close xbmc and load wmc and go to 'recorded tv', the list sort of 'auto populates' with the missing recordings. as in, they sort of 'reappear' slowly, as if wmc is scanning that network share.
As soon as I close that and load up xbmc, swmc shows all the r cordings again. So, sounds like an issue more with wmc rather than swmc?
I can confirm however, that after a couple of days, recordings do disappear - but they're not strictly all the ones on the network share. It can be only some of them. The most important thing, I think, is:
When I close xbmc and load wmc and go to 'recorded tv', the list sort of 'auto populates' with the missing recordings. as in, they sort of 'reappear' slowly, as if wmc is scanning that network share.
As soon as I close that and load up xbmc, swmc shows all the r cordings again. So, sounds like an issue more with wmc rather than swmc?
2015-01-15, 11:38
Just wanted to bump this thread.. it's obvious that it's not strictly a swmc issue, it's a wmc issue. Because the recordings get moved to the network share, they need to be re-indexed by wmc in order for swmc to list them.
What this means is that I need to close kodi, open up wmc, navigate to 'recorded tv', let the shows 'populate' there, then close wmc and open kodi again, upon where swmc can list them.
There's obviously some sort of indexing that's going on with wmc. But I've tried just leaving the 'recorded tv' screen open in the background, and that doesn't seem to trigger anything. If only we had access to some MS source code
So my query now is, can we somehow 'trigger' this refresh somehow, automatically?
What this means is that I need to close kodi, open up wmc, navigate to 'recorded tv', let the shows 'populate' there, then close wmc and open kodi again, upon where swmc can list them.
There's obviously some sort of indexing that's going on with wmc. But I've tried just leaving the 'recorded tv' screen open in the background, and that doesn't seem to trigger anything. If only we had access to some MS source code
So my query now is, can we somehow 'trigger' this refresh somehow, automatically?
