Too much memory usage w/Fanarts (3 Viewers)

[tourettes]

I was just looking at this again trying to fix it, this sort off tool popped in my mind to give it a try. It does lower the allocated memory of mediaportal when looking at taskmanager so I figured; it seems to do it's job.

Enable the virtual memory size column in Task Manager settings, it should show that MP VM allocation increases.

So this is no solution. Do you have a better one? And don't say do not use that much images, that skin, or that absolute folder path

Sorry, haven't yet read the thread thru, but might be that some skins are using unsupported ways to handle things like fan art.

 

[joz]

Sorry, haven't yet read the thread thru, but might be that some skins are using unsupported ways to handle things like fan art.

Well it could be because I've set the multiimage folder path myself. I pointed for example the basichome button "movies" to the moving pictures backdrops folder.

I would really appreciate if a dev, if you have time tourettes, take a look at this. I find it really a big improvement being able to use the multiimage in such a way in a skin, it's just buggy for now and probably never intended to be used like I have.

I'll see if it helps when I copy paste all moving pictures backdrops to the skin animation folder and use that folder instead.
Oh wait, I think I've tried that already. Didn't copy paste anythin, created couple of junctions (similair to hard links), easier.


-----EDIT-----

Just checked the VM size, tourettes desc. of how a "ram optimizer" works seems logically to me however I cannot confirm this currently testing this issue;
Whenever the RAM is "freed" by the tool it does not increase the mediaportal.exe VM size.
The VM does increase but only when changing images, not when the free ram tool is doing it's cleanup round.

So I just came to the conclusion I need to test this properly and for a long period of time, which I have not yet. I will and report back. I think tourettes is right though and this is no solution at all.

 

[joz]

This problem still exists for me with MP 1.1 beta.

 

[tourettes]

This problem still exists for me with MP 1.1 beta.

I guess no one in team uses skins that have fan art (...use the multi-image against the purpose how it is designed). I would assume that multi-image is just loading new pictures (and eating RAM) and it won't relase the old pictures as it is not designed for fan art usage.

 

[tourettes]

I had a quick look on the source code of Multi-Image class

public void LoadImage(int image) <-- loads image

public override void FreeResources() <-- unloads all images


and during rendering following code should release to previously used image:

              // swap images
              m_images[m_currentImage].FreeResources();
              m_images[nextImage].ColourDiffuse = (m_images[nextImage].ColourDiffuse | (long)0xff000000);
              m_currentImage = nextImage;

That would be a good starting point for someone who wants to debug the issue.

 

[vl002001]

i've always used an loved streamedmp, but this has made it unusable for me. hope someone finds a fix soon.

 

[joz]

I hope someone good debug this too!
I do have some C# experience myself so I might give a go at it but I'm not really into windows programming (yet)

 

[NikeNeGerek]

Hi all,

I've entered this bug to mantis, but i cannot find it now Can anyone help?

 

[tourettes]

Hi all,

I've entered this bug to mantis, but i cannot find it now Can anyone help?

Only team members have write access to Mantis. Currently it is not even known if this is a real bug or skins just abusing the GUI control (who knows maybe it is intended behavior that Multi-image class is caching all the images that it has been used to load.)

 

[NikeNeGerek]

Hmm, then i've entered this to somewhere else. Is there any other google area that this bugs are entered? It's been months ant i just wanted to check.

An obvious error like this should be solved by now. Since i got this error, I'm not using custom backdrops