Not feeling any pressure All I've had to do so far is speculate wildly!

So if I'm understanding correctly, the updated values from char X are not written out to the relevant section of the saved vars file after you log out from Char X, but for other characters that does work? And is that dependent on being in a VR zone?

If so (VR part aside), I begin to suspect that the player deactivate code in the addon is at fault - i.e. the new values are not being written out. You can inspect the model in game, if you really want to, using /script d(PL_TIMERS.timerData) That'll dump the values to chat, and if you then log out the same values (minus a few secs) should be written to the file.

The assumption to check here is that the file is definitely being written. I know opening it in notepad++ makes that easy to check as it'll ask you every time if you switch from ESO to notepad++ after a change if want to reload it. Should the file mysteriously not get updated after logging out of character X, then the bug is almost certainly in the addon (here, if you're interested!)

Ah OK so the saved variables are 'wrong'.

It could be, it's more likely to be my code tho You can test that quite easily. In the saved variables for each timer you'll find a property called key with a value like "2_8_1". You can plug those values (2, 8 and 1) into GetSmithingResearchLineTraitTimes to see what it reckons.

/script d(GetSmithingResearchLineTraitTimes(2, 8, 1))

... should be returning close to the values you see in the saved variables for duration and remaining. Tho bear in mind the saved vars aren't written out as soon as they change, so you need to log out or something to cause them to save. And obviously it should always be correct! This can only be done on the character who owns the research, but it'd be interesting to see if that function returns the wrong values, or not.

Not necessarily, evidently it doesn't do what I thought, so I suspect it might only be true when you are in a VR dungeon or such. That's an aside though, the real tell would be the timestamps.

I guess just keep an eye on it and if the issue arises again it'd be interesting to see what GetTimeStamp() gives you.

Stranger and stranger. I have a DC character who just hit VR1 so I will see if I can reproduce that at all if I go to the AD areas.

Edit:
If you like, try this slash cmd on the two characters in the three possible situations (one non-veteran, one veteran in VR area and one veteran in non-VR area)

/script d(IsUnitUsingVeteranDifficulty("player"),GetTimeStamp())

The value should be true/false (if VR is on) followed by the correct epoch timestamp (you can see the current timestamp here).

You could also try /script d(FormatTimeSeconds(356521, 9, 0, 1))

Which should always give you "4 days 3 hours 2 minutes 1 second"

It'd be interesting if either of those was wrong in the same situations as when your timers are wonky.

That is ... very funky. I've failed to reproduce it with my characters (one char with 6 slots going, 3 blacksmith, 3 clothing, one of which is, IIRC, the 8th trait).

I have no idea what could be wrong. I need to be able to reliably reproduce the problem myself in order to investigate further unfortunately.

Is the clock on your PC definitely correct? I just did a quick check and found that moving the clock on my PC forward by 2 hours with the game running causes the timers to all shift by 2 hours as well. It can probably be ruled out as the cause tho, cos switching characters just shouldn't shift the clock by 6 days.

Here are some technical details which might help you identify a cause:

If you're logged in as character X, character X's timers are updated 'for real' from the game. All other characters that have timers go through the process described in the next paragraph. Updating 'for real' involves asking the game for the total duration and remaining time for every research line. The game factors in your skills returns the remaining time, and total duration. When you log out those data are written to saved variables. That data also includes the time at which the data was acquired. If you quit (rather than log out then quit), the saved variables might not get written, but assuming you have not started any new research then the data is still correct (the addon will account for research that completes while it isn't looking).

This makes the passive timers really simple - when you're logged in as character Y, all the addon has to do to work out how long left is subtract two timestamps (time now - timestamp of the data) from the remaining time, to give an updated remaining time. That calculation always uses the persisted data from the last time you logged in as character X so that errors do not accumulate. All the timestamps involved come from the game, and in fact the function to difference the two times is part of the API too.

So, that is why I'm stumped, I just can't see why/when the value is inflating by 20%. I let the game handle all the skill-related stuff and don't update the data if the character is not logged in.

Fix on its way for the "Enable alarms" bug Thanks for reporting. I will look into the 'current character should be first' bug when I have more time.

Also bumped the versions the addon is listed as compatible with here on EsoUI so maybe people will see it now