Automatic updates didn't happen for several days in Other Emsisoft products Posted April 29, 2016 · Report reply > If you could start an update while a previous update appeared to be frozen/stalled, then> the previous update wasn't actually stalled and it may have just been a UI glitch.A three-day failure to update its signatures, AND no decent alert to the user saying thatthere was a problem is FAR MORE than a 'UI glitch'. It's a serious fault.I note that in another thread someone else recently complained that the tiny systray shield'scolour-change is just not adequate, especially for older eyes on high-res screens - as a way ofnotifying the user of a serious issue.[http://support.emsisoft.com/topic/20090-eam-shows-no-protection/]> It would also double the number of rows in the update log table of the SQLite database, which> would cut the number of updates that get logged in half. This is the sort of thing that we> generally keep in debug logs rather than in regular logs.... which would be fine if anyone ever had debug logging on when this occurs. Debug logsare no good for things that users can't reproduce. You must know that.> [killing stalled updates] That wouldn't solve the problem, and the user would be in the same> bad situation. No updates, and no clue why.Not correct. I see you snipped my suggestion that when such a 'kill' is done, it would belogged. So while, yes, it wouldn't fix the problem - but then no-one seems to understandhow to fix the problem - it would not the leave the user without any clue. There would bea log entry saying that the stalled update had been detected. At least we'd then all knowthat these presumed stalled updates were really happening.> Debug logs are the way that developers find out where a problem in the software is. Without them,> they have no way to know why something isn't working as expected. They can't just go through> millions of lines of code and hope they stumble upon the part of the code that is causing the> problem, and just so happen to notice an issue with that code that they overlooked when they> wrote it/updated it. The only time bugs get fixed without debug logs is when our QA team can> reproduce the issue in their own testing.Then you have a fundamental design problem, don't you? Debug logs are not "the way", they'rejust one way of finding out why things don't work. There needs to be a middle ground, wherewhen users never have debug logging on when a problem occurs, developers have to find anotherway to collect basic info - maybe not enough to pin down exactly why something is going wrong,but enough to /prove/ that it is.I lead a programming team before illness forced me to stop work. We occasionally had this sortof problem, and fixed it with a basic trace that ran all the time in whichever specific part ofour product until the reported problem happened again. We were lucky (compared with you) that ourcustomers were on a corporate network and so we were able to have our product send those smalllog files to us automatically and we received and filtered them automatically until one showedwhat we needed to know. Obviously you can't, in these days of angst about apps that 'phone home',have EIS send logs to you without the customers knowing, but it should be possible to create (ifyou like) an extra log that records some small details about the start and stop of the updateprocesses. If you're so concerned about its impact on the SQLite databases put it somewhereelse. It has to be active all the time so that it's active when people hit the problem. But forgoodness sake, do something about this problem.> Obviously, if our management thinks that adding some of your suggestions is a good idea, then> they will have our developers work on it.Do your management know about any of my suggestions?