+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: PVR & Live TV Support (https://forum.kodi.tv/forumdisplay.php?fid=167)
+---- Forum: Windows Media Center (WMC) (https://forum.kodi.tv/forumdisplay.php?fid=205)
+---- Thread: WMC as the backend - released (/showthread.php?tid=171216)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
RE: WMC as the backend - released - krustyreturns - 2013-09-20
(2013-09-20, 00:08)ferretlegs Wrote:(2013-09-19, 22:11)krustyreturns Wrote: Hi Everybody,
A new version of the server (1068) and client (1011) are up on the website. See the change log for what has fixed and added. Thanks to Scarecrow420 and Hoopsdavis.
--kr
Brilliant! Will test this out today - quite a change log there, thanks again for all the work you guys. Just a quick question to confirm that it is ok to install the server straight over the top? No need to uninstall old version? Also, same with client, just replace the folder and away you go?
In both cases you should be able to overwrite the old version. The addon might get a little confused as to whether it is enabled or not, but you should be able to resolve that easily enough.
(2013-09-20, 00:19)Powerhouse Wrote: Did I miss somewhere in the Change Log that this version was also supposed to fix the slow channel change? Thought this version was going to have that?
lol. Our first cut at that was in the previously released version (I guess you didn't notice much of an improvement). This version is mostly bug fixes.
RE: WMC as the backend - released - scarecrow420 - 2013-09-20
This changelog item is the one that gies more consistency in the channel change times but it doesnt really speed them up from the previous "best case" cases. It gives a big improvement over the random 10sec+ changes though
- Improved handling of audio track descriptors
Also for anyone who needs to submit logs, you should consider setting the option "LogReplyMessages" to true in the config.xml file. It will give us more information to work with
config.xml is located in C:\ProgramData\VDsoftware\ServerWMC\config.xml
Powerhouse if you still have your double recording issue, could you set LogReplyMessages to true, and upload a new log? I guess it will just confirm that you do infact have double entrries for recordsing being sent back to the client, but its good to confirm. As krusty said, everything from the log you posted looks OK, ie we dont actually see a double request being sent or anything like that, so definitely worth checking that WMC doesnt have your recorded TV folder added to the library (since recorded TV is automatially part of the library). I also think in this situation, that WMC itself will show double entries in the library for the recorded shows, so thats another thing to check
RE: WMC as the backend - released - krustyreturns - 2013-09-20
(2013-09-20, 01:09)scarecrow420 Wrote: This changelog item is the one that gies more consistency in the channel change times but it doesnt really speed them up from the previous "best case" cases. It gives a big improvement over the random 10sec+ changes though
You are right about this, somehow it got left off the change log. I just updated it.
RE: WMC as the backend - released - ferretlegs - 2013-09-20
(2013-09-20, 01:09)scarecrow420 Wrote: This changelog item is the one that gies more consistency in the channel change times but it doesnt really speed them up from the previous "best case" cases. It gives a big improvement over the random 10sec+ changes though
- Improved handling of audio track descriptors
OK, I've had a quick test with the new version and I can confirm that for me channel changing is slightly slower (maybe a second or two), but does feel more solid and consistent. A reasonable trade off I think, compared to occasional timeouts etc on some channel changes. I've gone from probably 4 or 5 secs to say 6 or 6.5 on average, but no unusual behaviors this time.
I also tested the instant record button which now works, but unfortunately the original stream does peter out for me after a few secs every time, even though I have multiple tuners. So for some reason the instant recording isn't firing up on another tuner it seems.
Overall this new version does seem to be feeling more 'solid' in terms of general consistency whilst using.
RE: WMC as the backend - released - scarecrow420 - 2013-09-20
(2013-09-20, 01:31)ferretlegs Wrote:(2013-09-20, 01:09)scarecrow420 Wrote: This changelog item is the one that gies more consistency in the channel change times but it doesnt really speed them up from the previous "best case" cases. It gives a big improvement over the random 10sec+ changes though
- Improved handling of audio track descriptors
OK, I've had a quick test with the new version and I can confirm that for me channel changing is slightly slower (maybe a second or two), but does feel more solid and consistent. A reasonable trade off I think, compared to occasional timeouts etc on some channel changes. I've gone from probably 4 or 5 secs to say 6 or 6.5 on average, but no unusual behaviors this time.
I also tested the instant record button which now works, but unfortunately the original stream does peter out for me after a few secs every time, even though I have multiple tuners. So for some reason the instant recording isn't firing up on another tuner it seems.
Overall this new version does seem to be feeling more 'solid' in terms of general consistency whilst using.
Im surprised anything got slower than before... is this "seat of the pants" feel or have you actually got timings from the logs?
Are you running server and XBMC on the same box or separate? What drive is the recorded TV on in the server (eg SATA, SSD, network location, etc) out of interest?
start a fresh log file (by stoping and starting ServerWMC app) then perform a bunch of channel changes (say 20 or so) and upload your log to pastebin? Im interested to see the timings in the log.
The process is
Close the old live recording
2013/09/20 09:52:37.193 StreamProc::Close> closed in 0.17 sec
Start the new one
2013/09/20 09:52:37.206 StreamProc> wtv recording started in 0.01 sec
analyze audio descriptors
2013/09/20 09:52:38.349 Parse> Total Descriptor parse time: 1.14 sec
remux to ts (this time includes the descriptor parse time above)
2013/09/20 09:52:38.906 StreamProc> 'ts' file created, size: 229,376 in 1.70 sec
then the backend is done
2013/09/20 09:52:38.906 Finished request OpenLiveStream in 1.88s
This "Finished request OpenLiveStream" entry is the total backend time it took to perform the channel change. Mine are usually all sub 3 seconds on the backend. Unfortunately it's up to how long it then takes XBMC to load the stream which is out of our hands and seems to take another few seconds and also seems to suffer from inconsistent/variable lengths.
Im interested to test using an SSD for the recorded TV drive, rather than the regular 2TB SATA I am using at the moment, to see if any more improvement occurs either in the backend or in XBMC accessing the ts file. But still, a backend time of 2 or 3 seconds is pretty low
RE: WMC as the backend - released - ferretlegs - 2013-09-20
Pretty much seat of the pants, you obviously get a feel for how long it takes and this version tweaked my 'this is taking longer than normal' sense. But you are right I have no data to back it up. I know its only fractionally slower though because every time I begin to sense it taking longer it comes on, so there is only a second in it.
XBMC is on another (high spec) win7 box connected to my win8 WMC backend on a gigabit backbone. WMC records to 4 x 7200rpm sata2 drives in hardware Raid10, which can tolerate recording 4 streams at once no prob. Pretty certain its not a performance bottleneck in that regard.
Will complete the test as requested. Believe me I'm not complaining about the speed at all, just honestly reporting my initial feedback and impressions after using the new version. Also, any idea why wmcserver might not be picking one of my other tuners for the instant record, rather than stealing the currently viewed stream?
RE: WMC as the backend - released - krustyreturns - 2013-09-20
(2013-09-20, 01:31)ferretlegs Wrote: I also tested the instant record button which now works, but unfortunately the original stream does peter out for me after a few secs every time, even though I have multiple tuners. So for some reason the instant recording isn't firing up on another tuner it seems.
Overall this new version does seem to be feeling more 'solid' in terms of general consistency whilst using.
I really thought I had these annoying tuner issues nailed. But you are right on this one, I just reproduced it. I guess there is always one more bug. If I can fix it quick (without breaking anything) I'll do a quick update.
RE: WMC as the backend - released - scarecrow420 - 2013-09-20
In terms of the stream dying when you instant record Im pretty sure this is by design for the time being. In other words, we didnt want to delay the build further by trying to do work in this area.
Without looking into to it too much, doing an instant recording on another tuner of the same channel you are already live vieweing (which remember, is actually performing a recording of that behind the scenes) would mean you are recording the same channel twice (one for live and one for instant recording) and thus tying up 2 tuners. Thats if its even possible to record the same channel twice simultaneously?
One way to make it work would be to somehow switch the live viewing to now be watching that instant recording but if thats even possible it would still cause a multiple second interuption on the client side while it switches to the recording. At least that wouldnt mean you have to do that yourself manually, when the stream dies (go to in progress recording screen and "view" it).
There are also then things to think about when using 2 tuners to accomplish this single task, what if another recording has to start, or you change channels again so on. Also this backend could have multiple clients talking to it and having tuners, so how to make sure we dont affect them (and what if one of them was watching the same channel you were and so on etc).
Ultimately we want to make Instant recording not start from when you hit the button but record as much of the current show as you have been watching it since. This is "good" PVR functionality that alot of PVRs surprisingly dont do (including WMC itself). But to do that are more big changes (not using thje built in WMC recording, but actually completing the live stream recording yourself, then saving it off rather than deleting it. also keeping it going even if the user now switches live channels etc). As you can probably see from my rambling there are alot of complexities to work out with this
So for the time being, doing something seemingly simple like instant recording a channel while you are watching it, and continuing to watch it while it is also recording, is still a bit clunky. But we dont want to do unnecsarry interim work in this area if it isnt heading in the right direction for the ultimate goal (instant recording saving as much of the current show as you have been viewing, rather than only starting from the point where you hit the record button).
Sorry to clog the thread up with dev talk Krusty, we should probably setup that separate thread in the PVR development section you spoke about, and move some of these more technical discussions there
edit: also ferret - in no way do i think you are complaining, i just like to see facts/logs to determine whether the subjective "taking a bit longer than i feel it should" can be pinpointed to a specific area. There is also a huge difference between the tuning hardware (USB, PCI or network based device for a start) and countries/broadcasts/formats we are all dealing with so the more logs I can see the more I can increase my understanding of where the times are
I also hope that you'll find whenever things seem to take a bit long, its not the backend which is consistently a few seconds... so it must be the actual streaming and XBMC side which we currently dont seem to be able to do much about. Grab a free prog called BareTail and have it monitor the ServerWMC log file. Setup some highlighting for the "Received Request" and "Finished Request" log entries and then it is very easy to see log entries fly by as you do XBMC interactions, and very easily see how long each request took on the backend
RE: WMC as the backend - released - Powerhouse - 2013-09-20
(2013-09-20, 01:09)scarecrow420 Wrote: Powerhouse if you still have your double recording issue, could you set LogReplyMessages to true, and upload a new log? I guess it will just confirm that you do infact have double entrries for recordsing being sent back to the client, but its good to confirm. As krusty said, everything from the log you posted looks OK, ie we dont actually see a double request being sent or anything like that, so definitely worth checking that WMC doesnt have your recorded TV folder added to the library (since recorded TV is automatially part of the library). I also think in this situation, that WMC itself will show double entries in the library for the recorded shows, so thats another thing to check
Ha, I don't need to anymore, the new Server and Client has fixed the issue.
You guys ROCK. Keep up the excellent work.
RE: WMC as the backend - released - ferretlegs - 2013-09-20
(2013-09-20, 01:42)scarecrow420 Wrote: start a fresh log file (by stoping and starting ServerWMC app) then perform a bunch of channel changes (say 20 or so) and upload your log to pastebin? Im interested to see the timings in the log.
Here is the log as requested: http://pastebin.com/hW91bbJa
Basically clean start and change channels a heap of times, thats it.
Noticed an error or two in there as well, but didnt notice anything wrong when doing the tests.
RE: WMC as the backend - released - scarecrow420 - 2013-09-20
Hmm the first thing that jumped out at me straight away on your log ferret, I can see that the step of starting the wtv recording is taking 4 seconds more often than not (but sometimes only 0.1).
On my logs this always takes mere fractions of a second
YOURS:
2013/09/20 10:06:46.922 StreamProc> wtv recording started in 4.59 sec
2013/09/20 10:07:04.062 StreamProc> wtv recording started in 5.47 sec
2013/09/20 10:07:18.803 StreamProc> wtv recording started in 4.56 sec
2013/09/20 10:07:35.993 StreamProc> wtv recording started in 4.86 sec
2013/09/20 10:07:50.553 StreamProc> wtv recording started in 4.45 sec
2013/09/20 10:08:04.044 StreamProc> wtv recording started in 0.05 sec
2013/09/20 10:08:18.914 StreamProc> wtv recording started in 4.57 sec
2013/09/20 10:08:31.384 StreamProc> wtv recording started in 0.05 sec
2013/09/20 10:08:42.104 StreamProc> wtv recording started in 0.08 sec
2013/09/20 10:08:52.864 StreamProc> wtv recording started in 0.06 sec
2013/09/20 10:09:19.535 StreamProc> wtv recording started in 5.59 sec
2013/09/20 10:09:39.105 StreamProc> wtv recording started in 6.44 sec
2013/09/20 10:09:58.545 StreamProc> wtv recording started in 4.60 sec
2013/09/20 10:10:16.176 StreamProc> wtv recording started in 5.01 sec
2013/09/20 10:10:36.296 StreamProc> wtv recording started in 4.57 sec
2013/09/20 10:10:51.756 StreamProc> wtv recording started in 0.04 sec
2013/09/20 10:11:17.157 StreamProc> wtv recording started in 5.69 sec
2013/09/20 10:11:36.147 StreamProc> wtv recording started in 4.62 sec
2013/09/20 10:11:57.838 StreamProc> wtv recording started in 4.61 sec
2013/09/20 10:12:14.808 StreamProc> wtv recording started in 4.84 sec
2013/09/20 10:12:34.888 StreamProc> wtv recording started in 0.04 sec
2013/09/20 10:12:49.158 StreamProc> wtv recording started in 0.02 sec
2013/09/20 10:13:08.099 StreamProc> wtv recording started in 4.57 sec
2013/09/20 10:13:25.799 StreamProc> wtv recording started in 4.50 sec
MINE
2013/09/20 09:48:37.006 StreamProc> wtv recording started in 0.05 sec
2013/09/20 09:48:51.720 StreamProc> wtv recording started in 0.85 sec
2013/09/20 09:49:03.479 StreamProc> wtv recording started in 0.01 sec
2013/09/20 09:50:13.305 StreamProc> wtv recording started in 0.02 sec
2013/09/20 09:50:24.207 StreamProc> wtv recording started in 0.91 sec
2013/09/20 09:51:00.081 StreamProc> wtv recording started in 0.02 sec
2013/09/20 09:52:37.206 StreamProc> wtv recording started in 0.01 sec
2013/09/20 10:00:16.987 StreamProc> wtv recording started in 0.01 sec
2013/09/20 10:16:18.738 StreamProc> wtv recording started in 0.84 sec
EDIT: looking at the code all of this time is taken up in the Microsoft Windows Media Centre library (ehiProxy.dll)> IRecorder::OpenMedia(TuneRequest pTuneRequest)
RE: WMC as the backend - released - krustyreturns - 2013-09-20
(2013-09-20, 02:18)Powerhouse Wrote:(2013-09-20, 01:09)scarecrow420 Wrote: Powerhouse if you still have your double recording issue, could you set LogReplyMessages to true, and upload a new log? I guess it will just confirm that you do infact have double entrries for recordsing being sent back to the client, but its good to confirm. As krusty said, everything from the log you posted looks OK, ie we dont actually see a double request being sent or anything like that, so definitely worth checking that WMC doesnt have your recorded TV folder added to the library (since recorded TV is automatially part of the library). I also think in this situation, that WMC itself will show double entries in the library for the recorded shows, so thats another thing to check
Ha, I don't need to anymore, the new Server and Client has fixed the issue.
You guys ROCK. Keep up the excellent work.
I'm sure I speak for scarecrow too when I say: WTF?? I can't see how any of the stuff we did could have any effect on this - but I'm not complaining either.
Re: RE: WMC as the backend - released - TheImmortal - 2013-09-20
(2013-09-19, 22:11)krustyreturns Wrote: Hi Everybody,
A new version of the server (1068) and client (1011) are up on the website. See the change log for what has fixed and added. Thanks to Scarecrow420 and Hoopsdavis.
--kr
You guys are awesome! I definitely appreciate all the hard work you do making this project a reality!
RE: WMC as the backend - released - scooper750 - 2013-09-20
Just out of curiosity, what PVR client addon are you guys using to interface with the WMC backend.
I haven't seen it mentioned. I'm running OpenElec and not sure what PVR client to choose.
RE: WMC as the backend - released - scarecrow420 - 2013-09-20
it's a new xbmc pvr addon called pvr.wmc plus a backend application called ServerWMC (that interfaces with Microsoft wmc recording epg etc services). Both were developed by krusty and now have a couple of devs contributing
The addon isn't packaged with xbmc as it isn't finished yet... Download it from the first post. Unfortunately I don't think we have Linux builds of the latest addon version but you can use the latest Linux one listed it should still work with the latest backend