• 1
  • 99
  • 100
  • 101(current)
  • 102
  • 103
  • 108
WMC as the backend - released
(2013-11-20, 06:30)wishywashy Wrote: First, thank you for the amazing plugin. I am useing it very successfully on two Windows 7 machines. However, I have run into a snag on a Ubuntu 13.10 machine. I am running XBMC 13.0 Alpha 10 and pvr.wmc(gotham)-linux-x86-1014 but I get:

21:15:40 T:2841365312 ERROR: PVR - Add-on 'Windows Media Center PVR' is using an incompatible API version. XBMC minimum API version = '1.9.0', add-on API version '1.8.1'
21:15:40 T:2841365312 WARNING: UpdateAndInitialiseClients - failed to create add-on Windows Media Center PVR, status = 6
21:15:40 T:2841365312 WARNING: UpdateAndInitialiseClients - failed to load the dll for add-on Windows Media Center PVR, disabling it

I appreciate any help.

I just checked and it looks like there is a problem with one of the linux gotham builds I received today, it looks like it is still the old version. But it is the 64b version that looks to be old, not the x86 one. Are you sure it is the x86 one that you are trying? Check the addon.xml file in the pvr.wmc folder, at the top you should see the version as 0.2.91 and the import version as 1.9.0.
Windows Media Center PVR addon (pvr.wmc) and server backend (ServerWMC)
http://bit.ly/serverwmc
(2013-11-20, 04:52)krustyreturns Wrote:
(2013-11-19, 17:31)awp0 Wrote: I've completed the test, and it shows a steep memory increase while watching Live TV (which starts at about 7:00am and stops at about 8:30am). The memory does not appear to be freed after the Live TV stops.

This could very well be related to my specific environment. I'd be interested to see if any other Windows users notice this behavior. Start Task Manager, locate XBMC process, and monitor the memory for at least 15 minutes or so while watching Live TV. If it's like mine, you'll see an immediate steep increase (to be expected) and then a gradual but steady increase for the duration of your Live TV session, about 45MB over 15 minutes.

Looks like the actual increase is from 149 (after the initial "jump") to 400 in the span of 80 minutes. So it's about 3MB per minute.

I tried replicating this today and you're right - live tv streams cause xbmc's memory usage to creep up. I also tried it with gotham and I see the same thing. I looked over the client code and I can't find a memory leak in the live-tv portion, not an obvious one anyway. Scarecrow if you get a chance you might try looking it over too, clearly if there is one there I am blind to it. There is a chance that this is an xbmc problem but that seems doubtful. Anyway thanks for pointing this out awp, we should try to figure this out.


Thanks for looking into this Krusty, I really appreciate it. And I'm happy to know that I'm not just crazy Smile

FWIW, I tested an HD MKV video for about 45 minutes just to make sure that this isn't some kind of a more generic issue with video playback in my environment, and memory remained stable. Following is a link to the perf monitor chart. You can see that playback is between about 7:00pm and 7:50pm. Memory is stable during playback and it's freed immediately afterword.
https://www.dropbox.com/s/qpx5dpgjpfpf5ou/xbmc-mkv.gif

I wonder if it would make sense to see if the problem happens during a recording playback, or possibly adding one of the recordings to the video library and playing it from there. Could it be a problem with this file format?
(2013-11-20, 06:52)awp0 Wrote: FWIW, I tested an HD MKV video for about 45 minutes just to make sure that this isn't some kind of a more generic issue with video playback in my environment, and memory remained stable. Following is a link to the perf monitor chart. You can see that playback is between about 7:00pm and 7:50pm. Memory is stable during playback and it's freed immediately afterword.
https://www.dropbox.com/s/qpx5dpgjpfpf5ou/xbmc-mkv.gif

I wonder if it would make sense to see if the problem happens during a recording playback, or possibly adding one of the recordings to the video library and playing it from there. Could it be a problem with this file format?

Well, we could both be crazy. I already tried the experiment of playing a wtv while it is recording and got the same leak result. I haven't tried just a wtv alone though.

Both of these use a portable readfile method that the addon imports from xbmc, really that is basically all the addon is dong when it plays live-tv, I wonder if they could leak. Scarerow's idea of checking against another pvr would be a good test if someone can do it easily, I can't.
Windows Media Center PVR addon (pvr.wmc) and server backend (ServerWMC)
http://bit.ly/serverwmc
Thanks. I'lI be out for most of the day tomorrow, but I should have some time on Thursday to install NextPVR to see if it has shows the same behavior. Though, I just let my SchedulesDirect membership expire, so I'll have to figure that out!

Anyway, I'm off to bed (east coast). Thanks again for all of your work on this. It's a really great PVR solution.
(2013-11-20, 07:03)krustyreturns Wrote: Well, we could both be crazy. I already tried the experiment of playing a wtv while it is recording and got the same leak result. I haven't tried just a wtv alone though.

Both of these use a portable readfile method that the addon imports from xbmc, really that is basically all the addon is dong when it plays live-tv, I wonder if they could leak. Scarerow's idea of checking against another pvr would be a good test if someone can do it easily, I can't.

Was curious about this so fired up XBMC12.2/pvr.wmc livetv on a remote Win7 machine and see this too. Using VMMap I get a quick increase in commit memory, then a steady rise over time. According to VMMap it is the heap memory allocation. My commit is rising about 3 Mb/min, but at this rate it would take like 16 hours to CTD XBMC on an OOM error.

Unfortunately ServerWMC works so well I blew away my NPVR.

scott s.
.
Trying to get this working right on my OSX Mavericks Client using XBMC Gotham latest nightly.

When I first installed the EPG updated and streams would start but then buffer every 2-3 seconds... not watchable. I did some digging and found that my SMB share to my WIN7 box was getting horrendous read speed performance. Could write to the share at upwards of 108MB/s (wired gigabit connection) but read speeds were a paltry 1.5MB/s way to slow to stream MPEG2 for sure. Ok, so I know the issue is with my Samba setup. Realtek Gigabit card on Win7 box (yeah I know RT sux). After poking around on the net I found that disabling Large Send Offset v2 for both IP4 and IP6 made all the difference. Now my Mac was able to read and write to the share at full speed. Awesome... except now when I go back to XBMC and try again I can't get any video stream to start. In looking at the logs I'm seeing that the Client is returning a StreamStartError. Debug output:

2013/11/19 23:13:15.852 StreamProc> 'ts' file created, size: 196,608 in 4.48 sec
2013/11/19 23:13:15.852 StreamProc> total time: 4.49 sec
2013/11/19 23:13:15.852 OpenLiveStream> stream path returned to client: smb://htpc1/Recorded TV/TempXBMC/LiveTV_10.10.1.148_Digital Cable_13_2013_11_19_23_13_11.ts
2013/11/19 23:13:15.852 OpenLiveStream> -----------------done-------------------------
2013/11/19 23:13:15.852 Finished request OpenLiveStream in 4.49s
2013/11/19 23:13:15.862 Received client request: 10.10.1.148|StreamStartError|smb://htpc1/Recorded TV/TempXBMC/LiveTV_10.10.1.148_Digital Cable_13_2013_11_19_23_13_11.ts
2013/11/19 23:13:15.863 StreamStartError> client '10.10.1.148' reports error opening stream, will close stream down
2013/11/19 23:13:15.863 StreamStartError> client '10.10.1.148' path to stream file: 'smb://htpc1/Recorded TV/TempXBMC/LiveTV_10.10.1.148_Digital Cable_13_2013_11_19_23_13_11.ts'
2013/11/19 23:13:15.865 WtvToPesDemuxer:Tonguearse> Guid header detects stream end
2013/11/19 23:13:15.865 Pass 'mux2ts':
2013/11/19 23:13:15.865 > WtvToPesDemuxer:Tonguearse> total guid headers processed: 532
2013/11/19 23:13:15.865 > WtvToPesDemuxer:Tonguearse> total data packets processed: 87
2013/11/19 23:13:15.870 Remux> ENDED, >>>>>>>>>> Run Time: 0.00 min <<<<<<<<<<
2013/11/19 23:13:15.883 StreamProc::Close> remux stopped successfully

Apparently Large Send Offload is doing something here... maybe something to do with resolving the network path properly on the client side? Maybe some path translation issue with spaces in the path? Again it seems to work with LargeSendOffload v2 enabled but then the overall network read speed to the share is too slow for the stream to play. Any ideas?
NVM... figured it out. Turns out the issue was with SMB shares showing up in XBMC. Apparently when that Large Send Offset was enabled there was some network translation happening or something that basically allowed XBMC to see the smb path correctly. I ended up applying the fix outlined here to get SMB working right in XBMC and now everything works GREAT!
http://forum.xbmc.org/showthread.php?tid=126007
(2013-11-20, 08:08)scott967 Wrote:
(2013-11-20, 07:03)krustyreturns Wrote: Well, we could both be crazy. I already tried the experiment of playing a wtv while it is recording and got the same leak result. I haven't tried just a wtv alone though.

Both of these use a portable readfile method that the addon imports from xbmc, really that is basically all the addon is dong when it plays live-tv, I wonder if they could leak. Scarerow's idea of checking against another pvr would be a good test if someone can do it easily, I can't.

Was curious about this so fired up XBMC12.2/pvr.wmc livetv on a remote Win7 machine and see this too. Using VMMap I get a quick increase in commit memory, then a steady rise over time. According to VMMap it is the heap memory allocation. My commit is rising about 3 Mb/min, but at this rate it would take like 16 hours to CTD XBMC on an OOM error.

Unfortunately ServerWMC works so well I blew away my NPVR.

scott s.
.

Yeah, it would take many hours in my environment too. However, one concerning thing is that the memory is never released. So if your XBMC is on 24/7 and you watch a few hours of TV per day then you'll see that XBMC process grow over the course of a week until it starts to run slow and crashes.
(2013-11-20, 06:49)krustyreturns Wrote:
(2013-11-20, 06:30)wishywashy Wrote: First, thank you for the amazing plugin. I am useing it very successfully on two Windows 7 machines. However, I have run into a snag on a Ubuntu 13.10 machine. I am running XBMC 13.0 Alpha 10 and pvr.wmc(gotham)-linux-x86-1014 but I get:

21:15:40 T:2841365312 ERROR: PVR - Add-on 'Windows Media Center PVR' is using an incompatible API version. XBMC minimum API version = '1.9.0', add-on API version '1.8.1'
21:15:40 T:2841365312 WARNING: UpdateAndInitialiseClients - failed to create add-on Windows Media Center PVR, status = 6
21:15:40 T:2841365312 WARNING: UpdateAndInitialiseClients - failed to load the dll for add-on Windows Media Center PVR, disabling it

I appreciate any help.

I just checked and it looks like there is a problem with one of the linux gotham builds I received today, it looks like it is still the old version. But it is the 64b version that looks to be old, not the x86 one. Are you sure it is the x86 one that you are trying? Check the addon.xml file in the pvr.wmc folder, at the top you should see the version as 0.2.91 and the import version as 1.9.0.

I checked the xml and the version and API numbers are correct. No worries though, this is my "mess around with linux box" so there are probably just issues on my end.
Hi Guys,

I have a question about frame rate...

It looks like most content I'm recording with WMC PVR is nearly 60 frames per second (59.xx).

Most other 720p TV content I've obtained over the years -- including iTunes TV Shows -- is 23.976 (24 frames per second).

Is there a setting I need to change in WMC/WMC PVR to record at 24FPS?
Is it not possible?
(2013-11-20, 16:45)newoski Wrote: Hi Guys,

I have a question about frame rate...

It looks like most content I'm recording with WMC PVR is nearly 60 frames per second (59.xx).

Most other 720p TV content I've obtained over the years -- including iTunes TV Shows -- is 23.976 (24 frames per second).

Is there a setting I need to change in WMC/WMC PVR to record at 24FPS?
Is it not possible?

2nd question, no it isn't. The broadcasts you recorded from are using that frame rate and windows just records it to disk. It depends on the source, but most of the content you will record of off tv will be at that frame rate. Movies though are typically shot at 24fps, so broadcaster use different techniques to convert these when broadcast to the higher rate. Most modern tvs can detect this conversion and convert back to the original rate during playback. So to answer your first question in my opinion there is no reason to convert, I sincerely doubt you will do any better playing with conversion software. Although when you start playing subjective subtle quality games people can convince themselves they see/hear all sorts of differences, ever heard of denon's $500 6ft eithernet cable?

(2013-11-20, 10:24)DaPooch Wrote: NVM... figured it out. Turns out the issue was with SMB shares showing up in XBMC. Apparently when that Large Send Offset was enabled there was some network translation happening or something that basically allowed XBMC to see the smb path correctly. I ended up applying the fix outlined here to get SMB working right in XBMC and now everything works GREAT!
http://forum.xbmc.org/showthread.php?tid=126007

Glad you worked this out, because I was lost Smile.

(2013-11-20, 08:08)scott967 Wrote: Was curious about this so fired up XBMC12.2/pvr.wmc livetv on a remote Win7 machine and see this too. Using VMMap I get a quick increase in commit memory, then a steady rise over time. According to VMMap it is the heap memory allocation. My commit is rising about 3 Mb/min, but at this rate it would take like 16 hours to CTD XBMC on an OOM error.

Unfortunately ServerWMC works so well I blew away my NPVR.

scott s.
.

Thanks for the extra analysis Scott. Very helpful.
Windows Media Center PVR addon (pvr.wmc) and server backend (ServerWMC)
http://bit.ly/serverwmc
(2013-11-20, 10:24)DaPooch Wrote: NVM... figured it out. Turns out the issue was with SMB shares showing up in XBMC. Apparently when that Large Send Offset was enabled there was some network translation happening or something that basically allowed XBMC to see the smb path correctly. I ended up applying the fix outlined here to get SMB working right in XBMC and now everything works GREAT!
http://forum.xbmc.org/showthread.php?tid=126007

TechLife,

I wonder if this problem DaPooch has solved is related to the problem you were having with atv2? Not sure if I remember what the problem was though.
Windows Media Center PVR addon (pvr.wmc) and server backend (ServerWMC)
http://bit.ly/serverwmc
Thanks krustyreturns, serverwmc is now working with AAC audio. I initially thought it was something wrong on my end since its running in a windows 7 VM in ESXI. Please let me know how to send you a donation.
Anyone get this going on ipad/iPhone yet? iOS client for ATV doesn't seem to work, error states unmet dependencies.
(2013-11-20, 22:31)DaPooch Wrote: Anyone get this going on ipad/iPhone yet? iOS client for ATV doesn't seem to work, error states unmet dependencies.

Assuming you're trying ATV with gotham, the guy who complies for ATV has not gotten back to me yet with build of the new version (1014). The unmet dependencies are do to that. You could use an older version of gotham (like alpha 9) and the version you have should work.

If anyone has tried it on an iphone/ipad I have not heard about it.
Windows Media Center PVR addon (pvr.wmc) and server backend (ServerWMC)
http://bit.ly/serverwmc
  • 1
  • 99
  • 100
  • 101(current)
  • 102
  • 103
  • 108

Logout Mark Read Team Forum Stats Members Help
WMC as the backend - released9