(2019-04-02, 03:51)dkoh Wrote: [ -> ]I've been chasing my tail on this for a while now (weeks? couple months?), and I finally found it only happens to Nox Silvo. Many, many reinstalls of Win 7 Pro x86 and this is what happens:
Music>Artist>Album>(sometimes it hangs here)>play a track (if I'm lucky).
Hit "next" or "back" or anything.
Freezes. Sometimes shows the circle spinner forever, sometimes crashes with a blank C++ error, sometimes gives the Windows, "xx has cashed, what do you want to do?" or "searching for a solution" message.
....
I switch to Estuary and everything works perfectly with the entire library scanned. I really don't want to leave this great skin, and I thank you for your work. I've been using Silvo since it came out, but music not working is a biggie for us.
(2019-04-02, 05:16)mikeSiLVO Wrote: [ -> ]....Alternatively Kodi may be having some kind of memory leak or there is some other underlying cause to all of this that has nothing to do with the skin.
Estuary does not do all of the things that this skin does so not every comparison is proof of a skin problem, however, I cannot be 100% certain that it is not a skin problem... 
Maybe @DaveBlake or another Kodi Dev can take a look at your log and perhaps see what the issue is 
I will resist the urge to blame the skin, although from what @
dkoh says about working on Estuary that does seem to be a smoking gun. For sure the issue is memory related, that is what all the errors are about. After the texture loading errors you hit this
Code:
DEBUG: CGUIMediaWindow::GetDirectory (musicdb://artists/22595/?albumartistsonly=false)
DEBUG: ParentPath = [musicdb://artists/]
ERROR: CThread::SpawnThread - fatal error 8 creating thread
DEBUG: ------ Window Init (DialogBusy.xml) ------
Error 8 is ERROR_NOT_ENOUGH_MEMORY to create a vital process, and hence the whirling cursor.
I have looked before for possible memory leaks especially for those with large libraries. There is an issue that is you leave Kodi running long enough it does
slowly eat memory resources. This is not because of any specific leak I could find, but seems to be a general memory management (or lack of it) issue. Small and big chuncks of memory all come from and are released back to the same pot which eventually can cause fragmentation. But this can't be what is happening on a newly started session, and also a greatly reduced music library.
There seems to be a problem related to recently added albums, how is that widget implemented in the skin @
mikeSiLVO ?
But the first memory error is
Code:
ERROR: CBaseTexture::Allocate - Could not allocate 16777216 bytes. Out of memory.
DEBUG: CBaseTexture::LoadFromFileInternal - Load of special://masterprofile/Thumbnails/b/b429e437.jpg failed.
and ~17GB for one image does seem mighty odd.
It is not the file size of b429e437.jpg that matters, but what Kodi texture processing gets as GetPitch() * GetRows() which is file format dependant. Perhaps something in that image and others is upsetting how it is read by ffmpeg?
It is not just the source files that need moving the clear art, but what is in texture cache too. All I can suggest is that you look a lot closer at these images or better still replace/remove them (and from cache). Are these same images shown when using Estuary?
