# Bug: debuff uptime on unaffected targets

**URL:** <https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109>\
**Category:** Warcraft Logs\
**Created:** [September 25, 2016, 7:36pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109 "2016-09-25T19:36:43Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Gwogobo](https://avatars.discourse-cdn.com/v4/letter/g/85f322/32.png) [@Gwogobo](https://forums.combatlogforums.com/u/Gwogobo)\
**Post date:** [September 25, 2016, 7:36pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109/1 "2016-09-25T19:36:43Z")

</div>

Evaluating [our attempts](https://www.warcraftlogs.com/reports/j3BzKkN8QDYMdbnr#type=auras&spells=debuffs&ability=204731&boss=1854&wipes=1) on H Dragons, I noticed this issue with the displayed uptimes on Wasting Dread. It’s pretty obvious there’s no way anyone could have that debuff for 100% of the fight, since the adds that cause it don’t spawn right away; I think what’s happening is that players who never take that debuff are shown as always having it [maybe since there are no events for the debuff beginning or dropping recorded for those players?] It’s easy enough to understand that this is bugged, but it makes the graphs harder to read.

---

<div class="post-metadata">

**Author:** ![Kihra](https://yyz1.discourse-cdn.com/flex029/user_avatar/forums.combatlogforums.com/kihra/32/1116_2.png) [@Kihra](https://forums.combatlogforums.com/u/Kihra)\
**Post date:** [September 25, 2016, 8:10pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109/2 "2016-09-25T20:10:07Z")

</div>

Do you have the original log file for this? Something has gone wrong where there are two IDs for Dread Horrors (thus causing the debuffs to go haywire). I need to see the original log file to understand why this happened.

---

<div class="post-metadata">

**Author:** ![Gwogobo](https://avatars.discourse-cdn.com/v4/letter/g/85f322/32.png) [@Gwogobo](https://forums.combatlogforums.com/u/Gwogobo)\
**Post date:** [September 25, 2016, 8:33pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109/3 "2016-09-25T20:33:20Z")

</div>

Not sure what the best way to share this is, but hopefully [this](https://drive.google.com/open?id=0BwplV1OFDIMsMHhRZTk5NEk5ckk) is good?

---

<div class="post-metadata">

**Author:** ![Kihra](https://yyz1.discourse-cdn.com/flex029/user_avatar/forums.combatlogforums.com/kihra/32/1116_2.png) [@Kihra](https://forums.combatlogforums.com/u/Kihra)\
**Post date:** [September 25, 2016, 8:42pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109/4 "2016-09-25T20:42:41Z")

</div>

That’s good yeah. Thanks. I noticed this bug occurring with Nightmare Ichor on Ilgynoth as well. I suspect this is Blizzard’s bug, since this issue is new to Emerald Nightmare and never occurred in HFC, but looking at the log file will let me figure it out.

---

<div class="post-metadata">

**Author:** ![Gwogobo](https://avatars.discourse-cdn.com/v4/letter/g/85f322/32.png) [@Gwogobo](https://forums.combatlogforums.com/u/Gwogobo)\
**Post date:** [September 25, 2016, 8:49pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109/5 "2016-09-25T20:49:06Z")

</div>

Well, if more data will help, I also have a [log](https://drive.google.com/open?id=0BwplV1OFDIMsU0dYV1lmOGpGMUU) that includes N Il’gynoth.

---

<div class="post-metadata">

**Author:** ![Kihra](https://yyz1.discourse-cdn.com/flex029/user_avatar/forums.combatlogforums.com/kihra/32/1116_2.png) [@Kihra](https://forums.combatlogforums.com/u/Kihra)\
**Post date:** [September 25, 2016, 9:07pm UTC](https://forums.combatlogforums.com/t/bug-debuff-uptime-on-unaffected-targets/1109/6 "2016-09-25T21:07:41Z")

</div>

I found the issue. Blizzard is identifying them as pets owned by the bosses. I just need to flag them as bogus pets. Will require a client uploader change though, so won’t be able to fix already-uploaded logs.
