Software Support > DOS/WinCab
wincab Version 3.1.4 Unstable?
konafan:
Same Thing again here is the results
0:00:31.09-LVL3-MQ_PROCESS: Re-processing message: BTN_PREVPG (delayed due to page turn animation)
0:00:31.10-LVL5-ARTCACHE: Replacing cache entry #38
0:00:31.12-LVL5-ARTCACHE: Replacing cache entry #39
0:00:31.14-LVL5-ARTCACHE: Replacing cache entry #40
0:00:31.16-LVL5-ARTCACHE: Replacing cache entry #41
0:00:31.20-LVL3-MQ_PROCESS: Processing message: BTN_PREVPG
0:00:31.21-LVL3-MQ_PROCESS: Processing message: -BTN_PREVPG
0:00:31.25-LVL5-ARTCACHE: Found cached pointer #38
0:00:31.26-LVL5-ARTCACHE: Found cached pointer #39
0:00:31.26-LVL5-ARTCACHE: Found cached pointer #40
0:00:31.26-LVL5-ARTCACHE: Found cached pointer #41
0:00:31.26-LVL3-MQ_PROCESS: Re-processing message: BTN_PREVPG (delayed due to page turn animation)
0:00:31.27-LVL5-ARTCACHE: Replacing cache entry #42
0:00:31.29-LVL5-ARTCACHE: Replacing cache entry #43
0:00:31.32-LVL5-ARTCACHE: Replacing cache entry #44
Chris:
Can you post the cache initialization info for that run?
konafan:
0:00:00.00-LVL2-ARTCACHE_INIT: ****** Initializing cover art cache ******
0:00:00.00-LVL2-ARTCACHE_INIT: Cover art size after scaling: 267x267
0:00:00.00-LVL2-ARTCACHE_INIT: Color depth: 16 bits/pixel, 2 bytes/pixel
0:00:00.00-LVL2-ARTCACHE_INIT: Bytes per cache entry: 143710 (1132 for BITMAP structure and row pointers)
0:00:00.00-LVL2-ARTCACHE_INIT: Requested cache size: 7 MB
0:00:00.00-LVL2-ARTCACHE_INIT: Cache entries: 51
0:00:00.00-LVL2-ARTCACHE_INIT: Actual cache size: 6.99 MB
0:00:00.00-LVL2-ARTCACHE_INIT: ****** Cover art cache initialization complete ******
wwwombat:
I'm digging up this old thread because the symptoms described look similar to what I was experiencing with old versions and still appear to manifest themselves with the new version (3.1.5).
The outline of the problem is that I start wincab, choose R for radio play and then proceed to rapidly flip through the pages until eventually wincab aborts. (Note that I tend not to do this myself but my son regularly uses the joystick to rapidly change pages, most often by going up/down one letter to get to a particular artist, whereas other people just do it to amuse themselves and be beyotches!)
Anyhoo, we're talking a song database of around 5,000 tracks at the moment split across a host of artists (it's what I consider the best songs of every artist in my collection)
My suspects for this error are to do with the cover art caching (I'm using the 6-CD album skin - cd6-1-ws) or some form of stack overflow as the message queue tries to handle an inordinate number of button/joystick presses. With Wincab 3.1.5 having a "Auto" default for ArtCacheMB (which equates to 32MB for Windows) I was wanting to see if the problem "disappeared"/was masked (since each individual cover art itself is usually only around 20kb). Hence I set DEBUG to 5, got a song playing and madly held the left mouse button depressed over the "next page" button until it fell over.
Here's some relevant extracts from the log.
Cache Initialisation:
--- Code: ---0:00:00.29-LVL2-ARTCACHE_INIT: ****** Initializing cover art cache ******
0:00:00.29-LVL2-ARTCACHE_INIT: Cover art size after scaling: 300x300
0:00:00.29-LVL2-ARTCACHE_INIT: Color depth: 16 bits/pixel, 2 bytes/pixel
0:00:00.29-LVL2-ARTCACHE_INIT: Bytes per cache entry: 181264 (1264 for BITMAP structure and row pointers)
0:00:00.29-LVL2-ARTCACHE_INIT: Requested cache size: 32 MB
0:00:00.29-LVL2-ARTCACHE_INIT: Cache entries: 185
0:00:00.29-LVL2-ARTCACHE_INIT: Actual cache size: 31.98 MB
0:00:00.29-LVL2-ARTCACHE_INIT: ****** Cover art cache initialization complete ******
--- End code ---
Bottom 10 lines of 42,988 lines of log:
--- Code: ---0:01:06.19-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:06.19-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:06.19-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:06.20-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:06.20-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:06.20-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:06.20-LVL3-MQ_PROCESS: Processing message: BTN_NEXTPG
0:01:06.22-LVL4-ARTCACHE: Replacing cache entry #101
0:01:06.24-LVL4-ARTCACHE: Replacing cache entry #102
0:01:06.26-LVL4-ARTCACHE: Replacing cache entry #103
--- End code ---
You'll see the last logged entry is a 'replacing cache entry'
I went nuts and set ArtCacheMB to its maximum of 1024 and tried again. Sure enough it got further this time.
Cache Initialisation:
--- Code: ---0:00:00.27-LVL2-ARTCACHE_INIT: ****** Initializing cover art cache ******
0:00:00.27-LVL2-ARTCACHE_INIT: Cover art size after scaling: 300x300
0:00:00.27-LVL2-ARTCACHE_INIT: Color depth: 16 bits/pixel, 2 bytes/pixel
0:00:00.27-LVL2-ARTCACHE_INIT: Bytes per cache entry: 181264 (1264 for BITMAP structure and row pointers)
0:00:00.27-LVL2-ARTCACHE_INIT: Requested cache size: 1024 MB
0:00:00.27-LVL2-ARTCACHE_INIT: Cache entries: 5923
0:00:00.27-LVL2-ARTCACHE_INIT: Actual cache size: 1023.89 MB
0:00:00.27-LVL2-ARTCACHE_INIT: ****** Cover art cache initialization complete ******
--- End code ---
Bottom 10 lines of 61,629 lines of log:
--- Code: ---0:01:24.39-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.39-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.39-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.40-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.40-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.40-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.40-LVL1-DO_INPUT: Mouse button pressed, b = 1
0:01:24.40-LVL3-MQ_PROCESS: Processing message: BTN_NEXTPG
0:01:24.42-LVL4-ARTCACHE: Creating cache entry #1402
0:01:24.45-LVL4-ARTCACHE: Creating cache entry #1403
--- End code ---
Notice that this time there are no references to replacing cover art entries. This makes me wonder if it's not cache replacement at fault but rather an inability to keep up with button presses. On the other hand I went madly pressing... it's seems as if my son only needs to look askew at the joystick and flick it a couple of times to get it to fall over (and when he does it I usually have DEBUG disabled)
Any thoughts / extra information I can supply?
Chris:
I'll have to add a debig for the message queue filling up... I never considered it a possibility for it to overflow so I don't trap for it. There is a failsafe that's supposed to drop messages on the floor rather than overflow but the failsafe could be buggy.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version