Kodi Community Forum

Full Version: WMC as the backend - released
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2013-11-20, 04:52)krustyreturns Wrote: [ -> ]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.

Krusty,

How hard would it be to write a pseudo client? Nothing fancy, it would not need to display video or anything, just start a live tv session and monitor the memory. That way you could determine if it is the server or in the addon / xbmc..
(2013-11-20, 19:06)krustyreturns Wrote: [ -> ]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.

I'm not sure how I would adjust that on my Linux server which does have a Realtek network card in it. My HTPC plays fine so I'm not sure it's related but I check it out. Thanks for the thought. I wouldn't have caught that.
(2013-11-21, 03:06)spinnaker Wrote: [ -> ]
(2013-11-20, 04:52)krustyreturns Wrote: [ -> ]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.

Krusty,

How hard would it be to write a pseudo client? Nothing fancy, it would not need to display video or anything, just start a live tv session and monitor the memory. That way you could determine if it is the server or in the addon / xbmc..

Great idea! There is a psuedo-client on the pvr master repo (called pvr.demo), it could be modified to add a fake live-tv mode that just reads from a canned file. That should point to the smoking gun (hopefully not pointed at me).
(2013-11-21, 04:13)krustyreturns Wrote: [ -> ]
(2013-11-21, 03:06)spinnaker Wrote: [ -> ]
(2013-11-20, 04:52)krustyreturns Wrote: [ -> ]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.

Krusty,

How hard would it be to write a pseudo client? Nothing fancy, it would not need to display video or anything, just start a live tv session and monitor the memory. That way you could determine if it is the server or in the addon / xbmc..

Great idea! There is a psuedo-client on the pvr master repo (called pvr.demo), it could be modified to add a fake live-tv mode that just reads from a canned file. That should point to the smoking gun (hopefully not pointed at me).

Actually I was thinking the other way around. Create an app that reads your WMCServer.. Something outside of xbmc. But your idea might work too. If it was still eating memory then we would know the issue is in xbmc.

Might it also help track down the directory issue?
(2013-11-21, 05:12)spinnaker Wrote: [ -> ]Actually I was thinking the other way around. Create an app that reads your WMCServer.. Something outside of xbmc. But your idea might work too. If it was still eating memory then we would know the issue is in xbmc.

Might it also help track down the directory issue?

Yes, you could use it as a simplified tool to understand the directory issue.
Often times when I watch a long show (1 hour or a sports event) and try to return to the epg or even the main xbmc menu, xbmc freezes up for several minutes. Is this a common issue with the software or just old hardware? I don't have any slowdowns when transitioning from other video types (movies and such).
(2013-11-21, 15:43)locoguano Wrote: [ -> ]Often times when I watch a long show (1 hour or a sports event) and try to return to the epg or even the main xbmc menu, xbmc freezes up for several minutes. Is this a common issue with the software or just old hardware? I don't have any slowdowns when transitioning from other video types (movies and such).

I've experienced this from time to time also, after watching on channel for a long period of time, when switching to another channel I sometimes get a freeze, I've also experienced once changing to the next channel or going to recorded tv the video would have major stutter and closing xbmc is the only way to resolution
(2013-11-21, 15:43)locoguano Wrote: [ -> ]Often times when I watch a long show (1 hour or a sports event) and try to return to the epg or even the main xbmc menu, xbmc freezes up for several minutes. Is this a common issue with the software or just old hardware? I don't have any slowdowns when transitioning from other video types (movies and such).

Does this happen only when watching live tv, like in hoops case?

When this happens to you again, note the time and save the server log. Post a link to the log here along with the time when it happened.
Ok, update on the memory problem:

This morning I configured NPVR, turned off the MCE recording services, disabled the MCE PVR add-in, and then enabled the NPVR add-in. I was able to reproduce this problem with NPVR in a shorter duration test. In fact, it looks pretty much identical, rising steadily from 102MB to 185MB in about 20 minutes, and not releasing the RAM after playback is stopped. Following is the graph:
Image

Since this has been validated on two different PVR's with three different users, I would assume that there is a real problem here and it's at the core XBMC level. Not sure what the next steps are here. I suppose I should post a thread about this in this main PVR forum to see if I can catch any XBMC developer attention?
(2013-11-21, 19:04)awp0 Wrote: [ -> ]Ok, update on the memory problem:

This morning I configured NPVR, turned off the MCE recording services, disabled the MCE PVR add-in, and then enabled the NPVR add-in. I was able to reproduce this problem with NPVR in a shorter duration test. In fact, it looks pretty much identical, rising steadily from 102MB to 185MB in about 20 minutes, and not releasing the RAM after playback is stopped. Following is the graph:
https://www.dropbox.com/s/18frv5qrsktc92n/xbmc-npvr.gif

Since this has been validated on two different PVR's with three different users, I would assume that there is a real problem here and it's at the core XBMC level. Not sure what the next steps are here. I suppose I should post a thread about this in this main PVR forum to see if I can catch any XBMC developer attention?

Have you thought of trying this using a gotham build? I've tried the gotham builds for a short time just out of curiosity and I noticed its more stable when it comes to moving through menus as well as going from live tv to recorded tv or any media. Maybe the issue is strictly Frodo.
(2013-11-21, 19:04)awp0 Wrote: [ -> ]Ok, update on the memory problem:

This morning I configured NPVR, turned off the MCE recording services, disabled the MCE PVR add-in, and then enabled the NPVR add-in. I was able to reproduce this problem with NPVR in a shorter duration test. In fact, it looks pretty much identical, rising steadily from 102MB to 185MB in about 20 minutes, and not releasing the RAM after playback is stopped. Following is the graph:
https://www.dropbox.com/s/18frv5qrsktc92n/xbmc-npvr.gif

Since this has been validated on two different PVR's with three different users, I would assume that there is a real problem here and it's at the core XBMC level. Not sure what the next steps are here. I suppose I should post a thread about this in this main PVR forum to see if I can catch any XBMC developer attention?

Awesome work awp. In my opinion it should go to the the pvr development section since its specific to pvr playback. I think you should put something like possible 'bug' or 'memory leak' in the subject heading to get attention. Depending on the response there, the step after would be to submit a bug report, but maybe someone there can point out something we are doing wrong first. Let me know if I can help.

Really great that you caught this. Hope you switch back to wmc, we need you.

(2013-11-21, 19:11)hoopsdavis Wrote: [ -> ]Have you thought of trying this using a gotham build? I've tried the gotham builds for a short time just out of curiosity and I noticed its more stable when it comes to moving through menus as well as going from live tv to recorded tv or any media. Maybe the issue is strictly Frodo.

I confirmed awp's results and also confirmed them for gotham - but for my stuff only.
Thanks guys. I'll put a thread in the dev section and see what happens.

Definitely switching back to MCE. I like your plugin and I'm sure I can work around this memory thing with a nightly restart.
Ok, here's the newly created thread in the PVR Dev forum:
http://forum.xbmc.org/showthread.php?tid=178572

Hopefully someone will bite.
Angry

If xbmc don't fix the stutter they are going to get smacked legs!

Angry
The Repository has been updated! The latest version in the repository is 0.2.91. If you are using XBMC Gotham, you must be on a compatible build compiled after November 8th.

There are some changes that have been made to help facilitate automatic updates in the future. In order to update through the repository, you must first uninstall your current version and then reinstall it through the repository. This will be the only time this extra step will be necessary. Otherwise XBMC will think they are two separate addons and you will end up with duplicate addons that may cause conflicts.

Please report back any problems with the repositories so that they may be corrected!

Frodo Repository Download Link

Gotham Repository Download Link