NewbyUser

One thing that I don't like about LiveGuard is that it seems to send every new file created on the device to LiveGuard upon execution. Even if it's an old, trusted and safe file. As you soon as I try to execute a new file that wasn't on my device before, ESET sends that to LiveGuard. Eg: If I just extract a newly downloaded 7zip installer from a zip file where the installer exe is trusted by literally every AV, as soon as I execute it, it gets blocked and submitted to LiveGuard for analysis. What's the point of this? A ESET's reputation check shows that the file is old with reputation status being Fine & green and the number of users is also high with a green mark. 
ESET should feed from this LiveGrid status and determine that the file is trusted, whitelisted and not necessary to submit it to LiveGuard for analysis. This alone would massively reduce the load on LiveGuard's server. This type of unnecessary submission needs to be avoided. Kaspersky and Norton makes use of their cloud reputation appropriately, which is something ESET is not doing here. The LiveGrid reputation should mean something. The LiveGrid and the LiveGuard combo should communicate with each other to determine what needs to be submitted and what not. Otherwise, LiveGuard servers are going to be bombarded with excessive unnecessary submission. 
Unnecessary submission is going to annoy even expert users.

https://support.eset.com/en/kb3415-enable-pre-release-updates-in-eset-windows-home-products

The way to stop this deceptive marketing practice is for Eset eStore to do as other web merchants do that I frequent.
These web sites will ask you on initial purchase if they can save your credit card data. If you say no, by definition you are making a one-time purchase. This also makes the auto-pay issue a moot point since without credit card data retained, there is no way to perform an auto renewal.
People need to petition Mastercard and Visa to make this a requirement for any web merchant that accepts their cards,

It sort of says it "helps" with identifying open ports and vulnerabilities, but doesn't seem to indicate it has any protective role. So how is it a critical security mechanism?  And on a side note, now I have to/should post about updates hanging again, this product is a mess. 
 

Such shady auto renewal policies are unethical, and possibly illegal in some countries.

I'm going to type this post again. I have the worst luck with this forum! I hit backspace to correct a typo in my post and Firefox went to the previous page I had visited, and I lost my entire post!!!! This has happened so many times on this forum! I have over 5000 post on Wilders and it has never happened on Wilders. The most annoying thing! I think i'm jinxed on this forum.
The user should be given the option to opt out of auto-renewal when they purchase a license and it should be easy to see. Also, it is confusing on where to go to opt out of auto-renewal once you have been enrolled. I thought myeset.com would be the place to opt out since that is the site for managing License and Devices. I wasted a lot of time looking for an option to opt out of auto-renewal on myeset.com. I finally found the option to opt out of auto-renewal on store.eset.com. It only gave me the option to opt out for the license I had just purchased. My old license still reported that it was set up for auto-renewal within the Eset Application.  I never was able to find any option on either website to disable auto-renewal for my old license.

 Please read my last response to itman above for more information and one possible solution for this problem. That will save me from having to type everything again.

Let's talk about Eset's Network Inspection Inspector processing since there is zip technical details on it.
To begin, Eset's network inspection processing  is not new and has existed on every EIS version I used dating to 2014. Past versions were relatively benign and non-troublesome. Once I configured Eset's network connection to accommodate my router, the settings remained stable. All this changed when Eset decided to get "cute" and expand network Inspection to examine router settings for the purpose of detecting suspected hacking activities. Great idea for off-the-self routers and the like that perform standard network initializing activities. A very bad idea for ISP provided routers with customized firmware settings.
The only positive thing in recent Eset versions is that now Network Inspection Inspector can be disabled via GUI setting which was not possible in the past.
For those who like technical details, let's get into those. Using a networking connection monitor such as TCPView, open it immediately after system startup time. Look for an ekrn.exe connection monitoring UDP port 138. Eset is examining network connections via proxy using this port. This is also where the problems start. My router is using NetBIOS which also uses that port to initialize it's router connectivity to my device. It then goes downhill network-wise from here.

First, verify your credit card data has been deleted from both your Eset eStore account and your myEset.com account.
When I likewise did my Eset license renewal via EIS GUI option, it set up a myEset.com account w/o my permission and set it to auto renewal! Also stored in that myEset account is the credit card number used for the purchase. Given all the security issues with myEset.com accounts being hacked, I also deleted the myEset.com account.
I for one have had it with Eset's overly aggressive license renewal/management crap. It's just "one more nail added to the Eset coffin" in regards to terminating the future use of this product.

But in the case of updating the end user is only half the equation. The company should be logging updates as well and trying to find a solution. Turning users into trouble shooters is not the answer. All this constant drone to submit logs is driving users away. 

Kind of ridiculous putting all the work on the end user. 

Next time this updating issue occurs, use a network connections monitor to ensure ekrn.exe has a solid connection to port 8883. You can use Eset's Network Connections tool or TCPView. I prefer TCPView since it will show if there are sync issues with the connection to port 8883, ekrn.exe is trying to establish. Eset uses port 8883 with fallback to port 443 for Push Notifications. If there are issues with getting that connection, it will cause this bork Eset updating behavior some are experiencing.

Kind of ridiculous putting all the work on the end user. 

This error has been around for quite a while, namely since the Windows 10 May Update.  
I find it really, very strange that the Eset developers/coders do not notice this and this error is taken over by Eset from build to build, as well as other bugs and all this moved me to stop constantly sending logs etc. and not to engage me so much anymore, 

Tip - if you delete your credit card info in your US eStore account, there is no way for Eset to perform an auto-renewal.

That is disappointing. This problem has been known for so such a long time, and a fix has been promised (and not working) also for a long time. I'm not interested in deploying an 'only briefly tested' version to hundreds of customers computers. Will the dll fix be able to be deployed by ESET Protect? Will this affect future 'uPCU' updates?
Whatever happened to automatic program updates by the way? This feature has been in policy for a long time and also has never worked. Wasn't this supposed to be fixed in version 8.0?

Costs me $5 a month, that's why.

The type of 2FA I want is the same as my bank provides and it does not require a smart phone to use.
When I log onto my bank web site, it requires me to select which phone number I have registered with them to receive a text message from them that contains a 6 digit security code. I can also receive a voice call containing the code instead. They then send me the code to my "vintage" non-smart phone. I then enter the code on the web page and the logon to the full bank web site proceeds. 
Note the 2FA elements deployed. The first is valid user id and password. The second is a one-time use served up security code.

I didn't do that but I did disable Eset from notifying about Windows updates and it seems to have gotten better.

Done. Yes I goofed, but so did eset by allowing a signin that was detected as being suspicious to begin with. Also 2FA should be implemented by now, it's allegedly been on the to do list for 6 months now  almost to the day.
 

Again as I've said while this could be an okay move there are plenty of VPNs out there compatible with Eset. A lot of people prefer their AV to only work as an AV

The below comment sums it up nicely:
In other words, you shouldn't disable it. If you do so, it needs to be done on the router.

Yes, I tested it and get same results here. If DOH is enabled I get no alert, when disabled alert returns (using Cloudflare or Quad9).

100% there is no problem of my system, there are one or more Eset problems and these are already running through several builds as confirmed by me and other users here!

I did a Firefox Reset and now Eset also properly alerts. Very strange indeed.
Of note, "Goback" button works sometimes and other times it does not.