SpellReminder

32 - Custom sound selected improperly repeats on spell expiry

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.

User When Change
Zidomo Sep 09, 2011 at 19:26 UTC
Zidomo Aug 11, 2011 at 14:55 UTC
Zidomo Aug 11, 2011 at 14:54 UTC Changed description:
  Please provide any additional information below.

- Took this long to confirm that the above problem happens consistently.
+ 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.
Zidomo Aug 11, 2011 at 14:51 UTC Changed description:
  Took this long to confirm that the above problem happens consistently.

- No, its not only when you are able to cast Lifebloom one more than one target (when in Tree of Life form). Yes, at that time, it plays the expiry sounds for all targets Lifebloom falls off of. In normal usage on one target, however,  the expiry sound frequently plays improperly twice.
+ 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.
Zidomo Aug 11, 2011 at 14:47 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • 9 comments
  • Avatar of Zidomo Zidomo Sep 09, 2011 at 19:26 UTC - 0 likes

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

  • Avatar of Zidomo Zidomo Aug 25, 2011 at 20:33 UTC - 0 likes

    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.

    Last edited Aug 25, 2011 by Zidomo
  • Avatar of oridan oridan Aug 15, 2011 at 19:05 UTC - 0 likes

    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 :)

  • Avatar of Zidomo Zidomo Aug 15, 2011 at 00:38 UTC - 0 likes

    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.

  • Avatar of Zidomo Zidomo Aug 14, 2011 at 22:12 UTC - 0 likes

    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.

  • Avatar of oridan oridan Aug 14, 2011 at 18:37 UTC - 0 likes

    fixed in 267 :)

  • Avatar of oridan oridan Aug 14, 2011 at 10:32 UTC - 0 likes

    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 :)

  • Avatar of Zidomo Zidomo Aug 13, 2011 at 14:51 UTC - 0 likes

    (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).

  • Avatar of oridan oridan Aug 11, 2011 at 15:01 UTC - 0 likes

    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!

  • 9 comments

Facts

Last updated
Sep 09, 2011
Reported
Aug 11, 2011
Status
Waiting - Waiting for more information.
Type
Defect - A shortcoming, fault, or imperfection
Priority
High - Strongly want to resolve in the specified milestone.
Votes
0

Reported by

Possible assignees