Software Support > DOS/WinCab
wincab Version 3.1.4 Unstable?
wwwombat:
No, not specific to the mouse. Joystick would have to be a suspect as well.... it was originally falling over when navigating using the joysticks (Ultimarc 360s connected via USB and not emulating keypresses - left/right for prev/next page, up/down for prev/next alpha) or trackball/mouse button combination.)
It's just that at the moment the (test) control panel is disconnected since I'm about to apply artwork to the true replacement metal panel before wiring it all up again. I still have the PC setup though with a keyboard/mouse for testing purposes and continuing front-end development under Mamewah.
I can try this weekend (work's almost finished for the day) and remap nextpage to a keypress and see if I can get it to fall over.
wwwombat:
Decided to try something different when I got home.
Set the values for FirstAutoFlipTimer and AutoFlipTimer to Disabled (used to be 60 and 30 respectively). Then I hit R for Radio and didn't touch a damn thing for well over two hours whilst I did other things and badly singing karaoke to the tunes. Worked like a charm.
I then stopped it and set the two of them to 10 and 5 respectively (which should still be way slower than me madly pressing on the mouse button). Sure enough, after 51 long minutes and 23 seconds, with it only playing a few songs via the PlayStimulator (and one wasn't playing at the time) it fell over.
I repeated this test a few times and invariably it fell over but never at the same place or at the same time ... all subsequent times were quicker (i.e. a couple of times it fell over before the first PlayStimulator kicked in)...
Don't get me wrong... the last log entry posted in jbdebug.log was ALWAYS a Replacing Cache Entry but it usually wasn't the same number to the right. One time the pages went through at least one complete cycle, possibly two (it was getting boring watching it waiting for it to fall over).
So, the only thing kicking the page turns was the automated one (CMD_NEXTPG) and it ALWAYS fell over at the same offset according to the Windows dialog box... not sure if you can track this back to the source code in question Chris but the offset was 6f502.
wwwombat:
As an aside, there doesn't seem to be a way to turn off the caching (my theory being I have a fast machine so who needs the caching if it's causing me problems.)
I tried using 0 and Disabled (which it didn't whinge about so I guess it regards it as zero) and reviewing the log after it falls over shows it is still replacing cached entries (albeit the highest cache number was probably only 4 or 5 with disabled (I think it was 0 when I had a value of 0 set))
For the sake of completeness I also tried multiple button presses on some other skins (I'm using the 6 CD one because I have a 1920x1200 widescreen monitor). Seems like none of the strip ones fall over (at least they didn't before I got bored) which is presumably because they have no art to cache.
Some of the other CD cover art ones I tried didn't fall over but then again I didn't try them long since the Animation of the page turning slowed everything down and stuttered the song badly (remember this is running on a 3.2GHZ Duo Core as well!) and it just became annoying given it's 2 in the morning and I should be asleep.
I turned the animation off inside the skins and eventually they fell over at the same offset as well.
G'night!
wwwombat:
Any thoughts yet Chris (does the abend offset any clues)?
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:
I've played with a number of possibilities but nothing solid yet.
I have to be able to cache at least enough album covers to fit on one screen worth of the skin, because I need to scale and rotate them as needed before display.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version