---
ISSUE: 4000 auctions scanned 0 added 0 removed 0 updated
Okay, so the scanner in 3.9.0.1063 assumes every auction listing will have an owner associated with it. If it finds an auction without an owner, it assumes that the AH page is still loading from the server. While that may have been true on retail wow, I noticed that on the Nostalrius AH there were a few listings that did NOT have owners associated for whatever reason. Any time the scanner would find one of these, it would time out waiting for the server to send the rest of the page (which it had usually already sent), try a couple more times, then give up and move on with the rest of the scan. Then at the end of the scan, when it's getting ready to update the DB, it notices it's missing a page of results and ends the whole thing without making any updates at all.
FIX: Auctioneer will request a page of auction listings three times before giving up, so my fix for the no owner issue is a simple check to mark a page as complete if we're on our last retry, making the relatively safe assumption that we should have gotten a valid page back by the third try if the AH server is actually working.
---
ISSUE: Stack splitting doesn't work correctly when posting multiple stacks
This one was ugly, sometimes posting stacks 2-3x the size you wanted at 1/2 to 1/3 the price per item
. I did some more print debugging and found it was an issue with the stack splitting mechanism. Whenever you pick up or put down an object in your inventory, the wow client will fire off an ITEM_LOCK_CHANGED event. So if you pick up an item, it's locked for moving and ITEM_LOCK_CHANGED is triggered. Then when you put it back down, it becomes unlocked again and another ITEM_LOCK_CHANGED event is fired off. The reason I bring that up is, when you click the Post Auction button in Auctioneer and it starts splitting/combining your stacks, it counts the number of ITEM_LOCK_CHANGED events to track the completion of each individual split/combine/split+combine operation. I found that it was counting to 3 for split, combine, and split+combine operations. But the problem is, it needed to count to *4* for the split operation, so any time it split a smaller stack off into an empty bag slot, it would not complete the operation fully. So it would see the same empty slot and try to split off a new stack into it, leading to the double/triple-sized stacks that actually end up posted to the AH.
FIX: I changed it to check for a count of 4 ITEM_LOCK_CHANGED events for split operations only. Combine and split+combine operations were left at 3 since they aren't broken.
---
And there we have it, two straightforward modifications that have addressed these showstopper issues for me. Hope these fixes work for some of you guys too.
