Tom Metro wrote:
> Niklas Brunlid wrote:
>> Tom Metro wrote:
>>> with speculation that the cause is memory fragmentation or just running
>>> out of memory when loading large lists of shows.
>> This is probably the cause then... I have something like 850GB of
>> recorded shows on my backend. At 1GB/hour, 1 hour/show, thats 850
>> shows.
>
> select count(*) from recorded;
>
> will tell you the actual number.
>
>
>> ...since the first list is loaded ok, and this happens even
>> if I stop the running program before deleting it, how can I be out of
>> memory? Is the list loaded twice or something when deleting shows?
>
> Yes, I believe there are several operations that trigger a reloading of
> the show list. Clearly one of those is a deletion.
>
> -Tom
Any recording changes on the backend trigger a reload, but the only
ones that seem to be at issue is the ones during deletion. I get lots
of reloads with it just sitting in that menu for several hours, but only
the ones done by the deletion seem to be at issue. I believe I have
only seen the "slow" after a deletion, not with things just sitting
there no matter how many reloads.
I wonder if something about the deletion code causes a actual memory
leak and not just fragmentation as that should be happening with all
reloads, but the deletion reloads seem to be a lot more likely to cause
the issue.
Given the event driven nature of the deletion I wonder if something
in the deletion code path causes the reload to not free its memory.
Roger
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
