Did 5 bosses in LFR today and now the tooltip shows I've done 5 bosses in normal too.

Edit: Also reported on WowAce - close this when the issue is fixed.

this does not only affect Antorus it seems, i just noticed it also shows both LFR and Normal ToS after a couple LFR boss kills

maybe the addition of Ulduar TW messed something up

LFR seems to have a lockout in 7.3.5. I'm thinking that is confusing the addon. You can check this ingame by checking Raid Info on a character that has done LFR that reset.

i might be wrong here, but wasn't the lack of LFR lockouts the reason the separate entries for each raid/wing exist in the SavedInstances.lua

if this change is actually here to stay, and im surprised blizz hasn't lost a word about it anywhere, those extra entries might need to be removed now

How does it behave for older LFRs? can someone check?

killed a random boss in LFR Throne of Thunder and the first boss in Dragon Soul and both have their own lockout now as well, making both show up twice in the SI window

didn't test any WoD raids but i would at least asume its the same for those as well

Yep. Done 11/11 LFR + 3/11 normal and it looks like this: https://imgur.com/a/QfvVB

I disabled every LFR wing from the options till this gets solved.

I took a look at this yesterday and LFR still has its own lockout. Previously, it'd run off of the Mythic ID and not need a lockout. I guess this system was messy? And Blizzard decided to finally give LFR its own set of values.

What's confusing is there isn't another ID in the game to represent LFR - There are still just the N, HC and M ID's. If this is to be how it is going forward, it's going to take some time to remove the entirety of LFR from SavedInstances code and rewrite areas that rely or refer to LFR. Something I personally wouldn't be able to do - I can only do house cleaning, small tasks etc.

Either the list in-game hasn't been updated with the LFR ID, or Blizzard have somehow managed to keep LFR under M ID, but have its own lockout - Either way, we could do with an official word from Blizz if this is intended, or a bug before anyone starts work on the addon.

I have a rather crude workaround for this to eliminate the LFR lockout from showing on the line with N/H/M:
This is on line 3991 in my SI file, but it might be different because I had made some other minor changes in the past.

        for diff = 1, maxdiff do
          if diff ~= 17 then
            if inst[toon][diff] and (inst[toon][diff].Expires > 0 or showexpired) then
              showcnt = showcnt + 1
              showcol[diff] = true
            end
          end
        end

Basically I just set it to ignore difficulty17, which is LFR. This keeps the SI window from showing the LFR lockout on the raid's main line but keeps it on the LFR line. Not ideal, because the addon is still storing the LFR lockout twice, just only using it once.

There's two LFR difficulty IDs: 7, and 17. See this wowpedia link

Regarding the saved variables: Ignoring LFR difficulties would also cause them to not be saved a second time here. I don't know if this is really a good idea, though; if anything, wouldn't it be logical to disable the LFR entries and have the lockouts stored regularly for them as well? Right now, there's two lockouts being stored, but in different formats.

This is what happens now, with the LFR lockout being detected properly:

	["Throne of Thunder"] = {
		["LFDID"] = 634,
		["Expansion"] = 4,
		["RecLevel"] = 90,
		["Show"] = "saved",
		["Name - Server"] = {
			[7] = {
				["Expires"] = 1517986801,
				["Extended"] = false,
				["Link"] = "|cffff8000|Hinstancelock:Player-1407-05CBEA3F:1098:7:512|h[Throne of Thunder]|h|r",
				["ID"] = 472285120,
				["Locked"] = true,
			},
		},
		["Raid"] = true,

And this is the special LFR entry that has been in place before:

	["LFR: Last Stand of the Zandalari"] = {
		["LFDID"] = 835,
		["Expansion"] = 4,
		["Raid"] = true,
		["Name - Server"] = {
			[2] = {
				true, -- [1]
				false, -- [2]
				false, -- [3]
				["ID"] = -3,
				["Expires"] = 1517986798,
			},
		},
		["RecLevel"] = 90,
		["Show"] = "saved",			

Since the Blizzard change, both will be stored, and displayed separately by the addon. This is what causes the display of two entries for each LFR lockout, one as part of the regular raid lockout (labeled "Throne of Thunder"), and the other from the special LFR handling code (labeled "LFR: Throne of Thunder").

The question is: Should LFRs be displayed inline instead of separately? This is what removing the special-case LFR handling would do.

Also, it is worth considering whether or not the legacy LFR handling must be removed in the first place. I'd argue that not only is this a lot more work, it's also changing behaviour that users are likely accustomed to (if the separate line was to be removed from the UI, that is). So it boils down to, is there really any point in removing all the LFR handling code on the backend?

My opinion: It depends on whether having them twice breaks something internally (something more difficult to fix than the UI), and whether removing the LFR entries while only keeping the regular lockouts would cause any bugs. Basically, whatever is least likely to break stuff should be the obvious choice here.

Unless someone with enough insight in the code is still around, maybe leaving the vars alone and simply hiding the duplicate LFR lockouts from the users would be the best course of action, for now. If there are other glitches we'll know where to look, and should be able to fix them easily enough.

Is this issue going to be addressed in the nearest future somehow? 1,5 months passed and lockouts are looking broken by default still.

I've looked into this, and unfortunately there are some side effects of the hack-fix suggested above, such as lockouts being displayed when the user sets an instance to "Always show".

The cleanest solution would probably be to just remove the newly-added lockouts and keep LFR tracking separate. If things change down the line, then this will need to be revisited, but at least there won't be numerous difficulty checks and special conditions all over the place to possibly undo.

Self-assigning while I test some changes.