WowAce

What steps will reproduce the problem?

1. Under Audible Warnings, select None. On a just single spell (the dreaded Lifebloom), select a custom sound for it (BeepBeepBeep). Have its alert slider set to 3 seconds.

2. In combat, cast both that spell as well as others to which no custom sound is attached.

What is the expected output? What do you see instead?

Expected: the custom sound for the single spell to play once at the 3 second mark and again at its expiry.

Instead: very frequently (seems to be rather randomly), the sound improperly plays twice in a row at expiry after hearing it once properly at the 3 second mark. The repeatable conditions seen so far: it only happens in combat and it only happens when there are other spells (without sounds selected) expiring either before or after Lifebloom.

What version of the product are you using?

r264

Do you have an error log of what happened?

No errors.

Please provide any additional information below.

Took this long to confirm that the above problem happens consistently. Its been happening regularly since about r258.

No, its not only when you are able to cast Lifebloom on more than one target (when in Tree of Life form). Yes, at that time, it plays the expiry sound for all targets Lifebloom falls off of. In normal usage on one target, however, the expiry sound frequently plays improperly twice.

No, its not "lag" or similar. The problem happens after the sound properly plays at the 3 second mark. There is never a repeat of the sound then; it only repeats under the above listed conditions at spell expiry. I've never heard it sound more than twice on a single Lifebloom expiry, but that's one more than should be playing. Its really distracting.

hmm quite a tricky one, i think i know what area of code this is happening at, so i'll try to do some investigation. Thanks!

(buys donuts for the police investigator)

Any luck yet? This problem is bad enough in raids to cause me to revert to an earlier working version (been so many that at this point I forget what actually works).

Hi Zidomo, i've issued a potential fix, although I don't think it will. I'll see if i can get any clues using Debug Mode later. It's possible that the spell is expiring, then being re-added again at the last second... possible cause is multiple detection methods.

It could also be the Bucket Event on UNIT_AURA - i'm not sure what the performance implication of changing this to single events will be yet, but i'll do some testing :)

fixed in 267 :)

Woohoo, nice work.

Yes, will be interesting to see if there are any performance implications to the fix using math.floor/ceiling, etc. when I have time to do CPU testing. Because as we all know, math sucks! ;). Unless you know offhand about any in r267.

Speaking of CPU, moving bars - - whether implemented through a library (LibBars, LibCandyBar or whatever) or custom rolled - - consume a large chunk of CPU time, regardless of anything else a mod is doing. So a future feature option to suggest is adding icons with cooldown numbers on them that can be chosen by the user instead of bars.

Have found over time that icon-based cooldown timers tend to use less CPU than bar-based ones (with bars showing). Will file a ticket with feature suggestions after the next release.

Well after testing, partially nice work.

r267 (r268-r270 are just me making the embeds for nolib versions "perfect") regularly throws errors. Doesn't appear to affect the proper single sound playing on spell expiry, but errors nonetheless.

Some time during an instance run casting a tracked spell:

["message"] = "SpellReminder-3.0\\modules\\cooldowns.lua:111: attempt to index local 'ci' (a nil value)\nCallbackHandler-1.0-6:147: in function <...onLoader\\CallbackHandler-1.0\\CallbackHandler-1.0.lua:147>\n<string>:\"safecall Dispatcher[1]\":4: in function <[string \"safecall Dispatcher[1]\"]:4>\n<in C code>: ?\n<string>:\"safecall Dispatcher[1]\":13: in function `?'\nCallbackHandler-1.0-6:92: in function `Fire'\nAceEvent-3.0-3 (Ace3):120: in function <Interface\\AddOns\\Ace3\\AceEvent-3.0\\AceEvent-3.0.lua:119>\n",
			["type"] = "error",
			["time"] = "2011/08/14 19:55:17",
			["session"] = 3725,
			["counter"] = 25,
		}, -- [999]

Nine minutes later in the same run, similar but not totally identical error thrown:

["message"] = {
				"SpellReminder-3.0\\modules\\cooldowns.lua:111: attempt to index local 'ci' (a nil value)\nCallbackHandler-1.0-6:147: in function <...onLoader\\CallbackHandler-1.0\\CallbackHandler-1.0.lua:147>\n<string>:\"safecall Dispatcher[1]\":4: in function <[string \"safecall Dispatcher[1]\"]:4>\n<in C code>: ?\n<string>:\"safecall Dispatcher[1]\":13: in function `?'\nCallbackHandler-1.0-6:92: in function `Fire'\nAceEvent-3.0-3 (Ace3):120: in function <Interface\\AddOns\\Ace3\\AceEvent-3.0\\AceEvent-3.0.lua:119>\n<in C code>: ?\n<in C code>: ?\n<in C code>: in function `CastSpellByName'\nInterface\\FrameXML\\ChatFrame.lua:1041: in function `?':\nInterface\\FrameXML\\ChatFrame.lua:4209: in function `ChatEdit_ParseText':\nInterface\\FrameXML\\ChatFrame.lua:3838: in function `ChatEdit_SendText':\nInterface\\FrameXML\\ChatFrame.lua:2571: in function <Interface\\FrameXML\\ChatFrame.lua:2564>:\n<in C code>: in function `RunMacroText'\nInterface\\FrameXML\\SecureTemplates.lua:379: in function `handler':\nInterface\\FrameXML\\Se", -- [1]
				"cureTemplates.lua:543: in function `SecureActionButton_OnClick':\nInterface\\FrameXML\\SecureTemplates.lua:583: in function <Interface\\FrameXML\\SecureTemplates.lua:575>:\n", -- [2]
			},
			["type"] = "error",
			["time"] = "2011/08/14 20:04:57",
			["session"] = 3725,
			["counter"] = 5,
		}, -- [1000]

As you can see by the counters, both errors repeated frequently.

fixed in r271

RE: Performance. The floor/ceil i used actually didnt fix the problem, so i can probably take those out anyway. There are probably a lot more performance optimisations that could be done, and maybe some memory leaks too. Will have to check these things out before the release :)

The problem has improved in r271-r272, but not totally.

On occasion, a selected expiry sound still plays twice at spell expiry with those revisions. But not nearly as often as it did prior to r267.

r273, same deal as with r271-272. Sometimes still get a selected expiry sound improperly playing twice at spell expiry.