Software Support > DOS/WinCab
wincab Version 3.1.4 Unstable?
wwwombat:
Assuming nothing's come to light yet can I request a possible option for the next release?
Alternatively, would you contemplate providing an option to turn off the caching logic (or let me know how if it can already be done) if that's a suspect?
Chris:
--- Quote from: wwwombat on March 04, 2008, 09:07:57 pm ---Assuming nothing's come to light yet can I request a possible option for the next release?
Alternatively, would you contemplate providing an option to turn off the caching logic (or let me know how if it can already be done) if that's a suspect?
--- End quote ---
No, that's not really possible.
Each image needs to be loaded, decoded from its native format, scaled/stretched/antialiased, and rotated before it's ready for the screen. The cache is a set of bitmap objects ready to receive the results of this loading. For a particular skin, all cover art images are the same size; I take advantage of this by pre-allocating a number of bitmap objects equal to the cache size, along with a set of paths corresponding with them. This way I am not continually creating and destroying bitmaps, which would lead to memory fragmentation over a period of time.
When a page is loaded, the four images are each loaded, scaled, etc. before the page change animation starts. On an image load request, the set of path pointers is checked; if it is an image that has previously loaded, the request returns the existing image object; otherwise, it is loaded into a temporary bitmap and written into the least recently used bitmap or the next completely unused bitmap.
Without storing the post-processed images somewhere, I would have to repeat the scale/rotation/antialias every time I need to update the screen, which would get ugly during the page change.
I think the "Replacing Cache Entry" at the end of the log is a red herring: the error is not in the replacement per se, it is somewhere between there and the next entry which never makes it to the log. I suspect my problem is in the jpg decode itself, and that whatever jpg is causing the problem is overrunning a buffer and destabilizing the system, causing it to crash sometime later. But it's easy for me to say that because I can just say "Well, you must have a bad jpg somewhere" and fob off responsibility for it. It would explain why no one else has reported it and I can't duplicate it, though.
How many albums are we talking about? Would it be completely unreasonable to do a search for *.jpg on your music subfolders (with hidden and system files displayed), ZIP them all up and E-mail them to celamantia@gmail.com? At least then I could replicate your conditions properly.
--Chris
wwwombat:
Thanks for the detailed explanation. It's very informative to know about the process behind the program.
Okay... keep in mind that I'm using the 6-CD cover skin on a 1920x1200 screen so there's a bit more loading/caching/scaling etc. going on. Some artists also exist with more than 14 'Greatest Hits' tracks (Beatles is the worst... they might get 3 or 4 "slots"). There's quite a lot of 1 or 2-hit wonders.
Also keep in mind that, due to my past problems with CD cover jpgs (as expanded upon in another post) I now save them all with particular options although I do keep some of them at a better size/resolution if I'm able to. I have managed to step through an entire cycle #-Z of all of my covers under wincab without problem (although if I do it again I can randomly fall over.. rarely in the same place). Thus I don't think any one particular cover is corrupt (but I'm willing to be told otherwise!)
The zipped up covers themselves are probably too big to email via your client (it covers 1,761 artists and runs at about 27MB by itself). Hence I've loaded it up to a mate's website and will send you the url via email separately. Won't you need a correctly tagged MP3 in each folder to trigger the display though or do you have other plans afoot (or could I provide my wincab db files and you fudge them in without wincab doing a DB update? Let me know)
Chris:
The tagging is irrelevant. It simply uses the first image in the song's folder that matches the file mask.
As far as a corrupt JPG goes, an error could destabilize the system without crashing it completely, causing an unrelated event later to push it over the edge.
Chris:
Well I still haven't solved this. I was going to fudge it with an auto-restart after a crash but it won't work in this case because it's dying in a way I can't intercept. *sigh*
One thing I've noticed is that my new video card, an nVidia 8500GT, is behaving differently from the Radeon 9600Pro I was using (the animation is a LOT slower on the nVidia which is a more powerful card), so perhaps the video driver plays into this.
--Chris
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version