Any update on the syncing issues? Basically sometimes overall damage for someone gets synced as a single fight's data. Syncing is basicly useless right now in raids until it's fixed. Not meaning to complain or anything I'm just curious what the status is on that, if any, and how I might be help to help track it down.
@Lind: It's still on my list. It's more work than it looks so I've been postponing it for fixing bugs and improving overall functionality.
@DaveE: I did multiple test runs in raid and my observation is that sync works fine as long as people don't reset data once they entered the raid instance. If they don't I didn't see any issues with sync. If people have contrary observations, please describe specifically what the problem is.
Also invalid recount version syncs seem to be not accepted, as is intended.
If people do delete data mid-raid, yes there is a known issue and I'm working on it. It's tricky because I need to do surgery on the main data-structure again to fix it. But as said it's being worked on.
As far as I see it recount should work fine with sync in raid as long as people have the discipline of not deleting data during it.
@mazzymaxim: You are using an old version of recount. Update to a newer one and this problem is already fixed.
I was skeptical to bring this here at first, but I'm almost certain now that Recount is causing my WoW client to lock up on exit after a large amount of data collection has occured. It seemed like every time after a raid that my client would just freeze when I tried to exit (sometimes I could end task, sometimes I had to hard reset). A friend of mine mentioned he was having the same problem, and it started about a week ago when he began using Recount. So, after our run tonight, he exited, and locked up, and I purged my Recount data before exiting, and for the first time in who knows how long, I successfully exited after a raid. Has anyone else noticed this behavior?
I was skeptical to bring this here at first, but I'm almost certain now that Recount is causing my WoW client to lock up on exit after a large amount of data collection has occured. It seemed like every time after a raid that my client would just freeze when I tried to exit (sometimes I could end task, sometimes I had to hard reset). A friend of mine mentioned he was having the same problem, and it started about a week ago when he began using Recount. So, after our run tonight, he exited, and locked up, and I purged my Recount data before exiting, and for the first time in who knows how long, I successfully exited after a raid. Has anyone else noticed this behavior?
Recount saves all it's recorded data before logoff so you don't accidentaly lose it after a DC. If you don't purge the data before logging off, it will take a longer time to log off, but it shouldn't freeze up (unless you're running on < 512 mb ram and/or a crap CPU, in which case you shouldn't even be running recount.) Just wait for a while, it should exit normally after max 30 sec usually.
I am familiar with this phenomena as well. This however is different. It's hard locked in what appears to be an infinite loop. I wait several minutes and it's still sitting there. Virtually no hard drive activity so I'm not inclined to think it's writing it's data.
Recount saves all it's recorded data before logoff so you don't accidentaly lose it after a DC. If you don't purge the data before logging off, it will take a longer time to log off, but it shouldn't freeze up (unless you're running on < 512 mb ram and/or a crap CPU, in which case you shouldn't even be running recount.) Just wait for a while, it should exit normally after max 30 sec usually.
Im also getting it, and im have P4 3.2 2GB RAM but that issn't any issue since there is virtually no processor or memory load at all (both under 5% at lockup) and the lockup sometimes can be solved just by terminating the process, but as mentioned sometimes the lockup is more sevre needed a reboot (and in my case atleast a forced reboot since comp refuses to reboot normally with wow still logged as active).
And been waiting atleast 10 min without it closing on it own and the taskmanager loggs wow as non responcive.
I did notice that it locked up longer than normally yesterday, but it didn't freeze up totally. If you're certain that you don't lock up if you clear the data, it's probably a bug and will most likely be fixed soon.
Hmm it's very weird. Recount has literally nothing to do with the storing process, that's the client doing directly from the lua table data. I could imagine that certain weird table contents cause issues and I'll investigate that, but currently Recount itself has 0 lines of code that are devoted to storing data.
I haven't seen the problem myself. Have people deleted their wtf/*/Recount.lua files, especially the per character ones and did the problem persist?
The lockup is not addon related. It usually is caused by doing certain quests on the Isle (I tested with no addons, did all the QD dailies and some of the Shatt dailies, then tried to log. Got the infinite loop.) I'm sure there are other conditions for causing the lockup, but it does look more Blizzard related.
The lockup is not addon related. It usually is caused by doing certain quests on the Isle (I tested with no addons, did all the QD dailies and some of the Shatt dailies, then tried to log. Got the infinite loop.) I'm sure there are other conditions for causing the lockup, but it does look more Blizzard related.
I wouldn't be so quick to dismiss Recount as the culprit. I do think you're right that certain conditions are what causes the problem, but what those are will probably be discovered by chance. I had a friend tell me that if he was healing (for example) and didn't do any damage, he couldn't reset the data unless he was on the healing tab. In other words, he couldn't reset the data if he was displaying a table for which there was no data for character.
I am familiar with this phenomena as well. This however is different. It's hard locked in what appears to be an infinite loop. I wait several minutes and it's still sitting there. Virtually no hard drive activity so I'm not inclined to think it's writing it's data.
Could be a Hardware issue, damaged OS/game install, very bad hard drive fragmentation, or maybe your HD is getting low on space?
I've been using recount for months and months, in Raids everyplace, and have never seen it cause a lock up...
(FYI, my AddOns folder takes up 124MB, and has 125 items in it...)
@DaveE: I did multiple test runs in raid and my observation is that sync works fine as long as people don't reset data once they entered the raid instance. If they don't I didn't see any issues with sync. If people have contrary observations, please describe specifically what the problem is.
Also invalid recount version syncs seem to be not accepted, as is intended.
If people do delete data mid-raid, yes there is a known issue and I'm working on it. It's tricky because I need to do surgery on the main data-structure again to fix it. But as said it's being worked on.
As far as I see it recount should work fine with sync in raid as long as people have the discipline of not deleting data during it.
I'll try telling the people in the raid not to reset once raid starts however I've seen the same problem when someone doesn't reset at all. A lot of people run recount and some of them forget to reset their data. The other day we did one pull on trash mobs in BT and someone ended up with some 90%+ of the dmg done after the sync doing more damage then the pull had total hitpoints. A possible work around to that is if a raidleader could force a clear on everyone in raid, unless I missed that option somewhere. Another issue could be if someone's client crashes and their data doesn't get saved, when they come back in they could have old data.
If I turn on "Nur Bosssegmente behalten" (Only boss segments retain) the whole trash (tested in hyjal) is added to the damagemeter of the boss. =/
And there is another thing... With this option I can't see the Damage/Heal of the trashmobs. And without this option I had to reset Recount to see a sumary of the whole trashmobs.
Could you merge the whole Heal/Damage of all trashmobs to a category named "trash" and put it between the data of the bosses?
And another thing: At Archimonde I had once a low frame rating till I closed the Recount window. The next fights it worked fine.
Here is also a bug:
"Recount-70066\\Recount_Modes.lua:298: attempt to index field '?' (a nil value)\nRecount-70066\\GUI_Main.lua:572: in function `UpdateDetailData'\nRecount-70066\\GUI_Main.lua:890: in function <Interface\\AddOns\\Recount\\GUI_Main.lua:697>\n(tail call): ?:\n<in C code>: ?\n<string>:\"safecall Dispatcher[2]\":9: in function <[string \"safecall Dispatcher[2]\"]:5>\n(tail call): ?:\nAceTimer-3.0\\AceTimer-3.0.lua:140: in function <...ddOns\\BetterInbox\\libs\\AceTimer-3.0\\AceTimer-3.0.lua:114>\n\n ---"
Recount segments per combat phase, a segment start as you enter combat and ends as you leave combat.
What you request is essentially not checking Keep Boss Fights Only. Then you will see trash segments.
Hyjal is tricky because depending how it goes you may not leave combat between phases, or between the last phase and the boss. Recount's segmentation doesn't know that a new phase starts so it keeps some trash with the boss.
So strictly it keeps segments that contain bosses, not segments that we would subjectively consider boss-only segments. Luckily for a lot of bosses this works very well. In BT basically only RoS will likely have trash in the boss segment due to the gauntlet. Other bosses are clean per my testing. Any boss where you have are certain to be out of combat before pull will work well, which is all of TK and SSC. But RoS and Hyjal are special cases. For now I don't really plan to fix this, because I think it works well enough. If I do eventually add bigwigs support for segmentation it will be completely optional so the problem will persist for those without bigwigs. I'm still not convinced that for those few cases it warrants to add bigwigs support. Storing segments is a fairly costly affair and I wouldn't want to lower people's performance mid-combat.
Message: ..\AddOns\Recount\Tracker.lua line 600:
attempt to index local 'who' (a nil value)
Debug:
(tail call): ?
Recount\Tracker.lua:600: SetActive()
Recount\Tracker.lua:1337: AddHealData()
Recount\Tracker.lua:346: parsefunc()
Recount\Tracker.lua:533: ?()
...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:146:
...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:146
[string "safecall Dispatcher[14]"]:4:
[string "safecall Dispatcher[14]"]:4
[C]: ?
[string "safecall Dispatcher[14]"]:13: ?()
...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:91: Fire()
Ace3\AceEvent-3.0\AceEvent-3.0.lua:70:
Ace3\AceEvent-3.0\AceEvent-3.0.lua:69
function Recount:SetActive(who)
if not who then end
who.LastActive=Recount.CurTime
end
and no error on load..
@DaveE: I did multiple test runs in raid and my observation is that sync works fine as long as people don't reset data once they entered the raid instance. If they don't I didn't see any issues with sync. If people have contrary observations, please describe specifically what the problem is.
Also invalid recount version syncs seem to be not accepted, as is intended.
If people do delete data mid-raid, yes there is a known issue and I'm working on it. It's tricky because I need to do surgery on the main data-structure again to fix it. But as said it's being worked on.
As far as I see it recount should work fine with sync in raid as long as people have the discipline of not deleting data during it.
@mazzymaxim: You are using an old version of recount. Update to a newer one and this problem is already fixed.
Recount saves all it's recorded data before logoff so you don't accidentaly lose it after a DC. If you don't purge the data before logging off, it will take a longer time to log off, but it shouldn't freeze up (unless you're running on < 512 mb ram and/or a crap CPU, in which case you shouldn't even be running recount.) Just wait for a while, it should exit normally after max 30 sec usually.
Skylinee,
I am familiar with this phenomena as well. This however is different. It's hard locked in what appears to be an infinite loop. I wait several minutes and it's still sitting there. Virtually no hard drive activity so I'm not inclined to think it's writing it's data.
Im also getting it, and im have P4 3.2 2GB RAM but that issn't any issue since there is virtually no processor or memory load at all (both under 5% at lockup) and the lockup sometimes can be solved just by terminating the process, but as mentioned sometimes the lockup is more sevre needed a reboot (and in my case atleast a forced reboot since comp refuses to reboot normally with wow still logged as active).
And been waiting atleast 10 min without it closing on it own and the taskmanager loggs wow as non responcive.
I haven't seen the problem myself. Have people deleted their wtf/*/Recount.lua files, especially the per character ones and did the problem persist?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI wouldn't be so quick to dismiss Recount as the culprit. I do think you're right that certain conditions are what causes the problem, but what those are will probably be discovered by chance. I had a friend tell me that if he was healing (for example) and didn't do any damage, he couldn't reset the data unless he was on the healing tab. In other words, he couldn't reset the data if he was displaying a table for which there was no data for character.
Could be a Hardware issue, damaged OS/game install, very bad hard drive fragmentation, or maybe your HD is getting low on space?
I've been using recount for months and months, in Raids everyplace, and have never seen it cause a lock up...
(FYI, my AddOns folder takes up 124MB, and has 125 items in it...)
I'll try telling the people in the raid not to reset once raid starts however I've seen the same problem when someone doesn't reset at all. A lot of people run recount and some of them forget to reset their data. The other day we did one pull on trash mobs in BT and someone ended up with some 90%+ of the dmg done after the sync doing more damage then the pull had total hitpoints. A possible work around to that is if a raidleader could force a clear on everyone in raid, unless I missed that option somewhere. Another issue could be if someone's client crashes and their data doesn't get saved, when they come back in they could have old data.
If I turn on "Nur Bosssegmente behalten" (Only boss segments retain) the whole trash (tested in hyjal) is added to the damagemeter of the boss. =/
And there is another thing... With this option I can't see the Damage/Heal of the trashmobs. And without this option I had to reset Recount to see a sumary of the whole trashmobs.
Could you merge the whole Heal/Damage of all trashmobs to a category named "trash" and put it between the data of the bosses?
Example:
trashmobs
boss1
trashmobs
boss2
trashmobs
...
And another thing: At Archimonde I had once a low frame rating till I closed the Recount window. The next fights it worked fine.
Here is also a bug:
What you request is essentially not checking Keep Boss Fights Only. Then you will see trash segments.
Hyjal is tricky because depending how it goes you may not leave combat between phases, or between the last phase and the boss. Recount's segmentation doesn't know that a new phase starts so it keeps some trash with the boss.
So strictly it keeps segments that contain bosses, not segments that we would subjectively consider boss-only segments. Luckily for a lot of bosses this works very well. In BT basically only RoS will likely have trash in the boss segment due to the gauntlet. Other bosses are clean per my testing. Any boss where you have are certain to be out of combat before pull will work well, which is all of TK and SSC. But RoS and Hyjal are special cases. For now I don't really plan to fix this, because I think it works well enough. If I do eventually add bigwigs support for segmentation it will be completely optional so the problem will persist for those without bigwigs. I'm still not convinced that for those few cases it warrants to add bigwigs support. Storing segments is a fairly costly affair and I wouldn't want to lower people's performance mid-combat.
Yes but I can't merge these trash segements... I can only see each trash group separately. And this is not always useful =/