@Tiarz: The combat log provide a source for each spell effect. Addons use that information to attribute the origin of the spell. Clearly the log lists the person the absorb is on as the source of the effect, hence the attribution you are seeing.
In order to understand what is really going on I'd need to see a raw combat log that starts with the effect procing at the healer until it actually procs the shield. Depending on the nature of what is in the log this may or may not be fixable.
@Tiarz: the latest alpha commit should now track this absorb.
@gresyth: are you using some UI package. It seems to me that it may be setting the row height to non-integer values, which is not a recount bug but a bug in that UI package if that's the case.
@Lombra: Hmm, not sure. I think it should be possible but might requires extra leg-work as currently everything is organized around combatant lists. Don't have disposable time so I won't be adding one any time soon. If anyone else wants to take a stab at making one, they should of course just go ahead.
Wowhead no longer provides the spell ids of the actual buff effect. It used to be possible to click on the effect and get its spellid, but no longer. So the second is sadly not what allows tracking of the effect. I'll need the spellid of the actual buff proc which will be different than the spell that causes the proc.
There are numerous settings that help you control aspects of resource collection. For example you can reduce the number of historical battles collected. Some modules can also be deactivated by deleting them from the TrackerModules directory. Also make sure to only collect boss segments and delete data before every raid run. Do not have time-based data collection on unless you want to get very high detail on a specific aspect. It's best to have that off in normal use because it will collect a lot of data.
It is very likely that what you are seeing here has nothing to do with Recount but rather is a behavior of WoW's reading saved variables. If the data loaded is too large is opts to return an empty table. This really isn't anything that Recount can address.
In general I would recommend resetting data before a raid, and making sure that some of the heaviest data collections (time-based data) are turned off.
I recommend only keeping boss segments and and perhaps lowering "Recorded Fights" setting to something low.
The latest commit fixes the issue Farmbuyer reported above. Recount would lose identification of cross-realm players and trigger rescan of all targets causing potential slowdown under certain circumstances. The fix should drastically improve performance in situations containing cross-realm combatants.
I've already tagged it for release, so people should be getting this version when they update.
I have also updated the RecountThreat module to be toc-current.
@Phanx: Still trying to reproduce. I get delete requests only at beginning and end of scenarios not otherwise. I have not experienced mid-scenario delete popups. Need more details to reproduce I guess.
@All: 5.3 version (toc bump) is out, including a minor monk guard absorb fix.
@Phanx: I'll look into it. I'm still traveling so won't be touching anything major for another week or so.
@Farmbuyer: I'll see if I can curb that problem. Thanks for reporting.