Kodi randomly leaves full-screen mode to smaller window at top-left-hand side of screen (especially on Intel NUC), leaving it locked up under Windows 10

Problem: Per title.  Affected was Kodi Leia, but can happen to any Kodi.  May also happen to other media players.

 

Explanation:  This is a manifestation of the EDID issue (also known as the "quarter screen issue") where:

•  Windows is losing the EDID for the display device (TV, projector) when the display is shut off or disconnected.

•  Windows then resizes the screen resolution to the "default" display device, which forces Kodi to resize as well.  This usually makes the Kodi display lower resolution (i.e. smaller).

•  When the display is turned back on / reconnected, Windows re-acquires the EDID and changes back to the original resolution.  

Kodi does not handle this gracefully.  

The result is that Kodi gets "stuck" in the lower resolution, which manifests itself as a smaller (i.e. lower-resolution) window at the top-left corner of the screen.  

Some people find that although Kodi is resized, it is still responsive, and so can be restored to full-screen mode via keystrokes.  In my case, it also locks up, forcing me to kill and restart it each time.

 

This may or may not affect a HTPC directly connected to a TV.  It may also seem to occur randomly, not every time.

The problem does appear to be exacerbated when:

•  The HTPC is an Intel NUC; and/or

•  There is a receiver between the HTPC and the display device; and/or

•  The receiver is relatively old.

Keeping the receiver on full-time might not help since older receivers might interfere with EDID acquisition even when active.

This does not seem to occur on Android since Android doesn't handle EDID the same way.   So if I had kept my Shield instead of getting a NUC, I probably wouldn't have this issue.(*)

Solution: Buy a "EDID emulator" device (like this one or this one).  I tried the second one and it seems to have fixed the issue.

You can also get a "Dr. HDMI".  This is the same thing but more expensive.

These devices lock the EDID to >one< resolution only.  So be sure the purchase the one that matches the intended resolution of your TV, projector or monitor.

(*) I exchanged the Shield for the NUC because the Shield didn't correctly support analog 7.1 audio.

VPN kill switch for single machine or IP address range on pfsense

There are obviously LOTS of ways to do this in pfsense.  This is just the way that I found, which seems to work.

This rule should prevent an individual machine from "talking" using the default non-VPN WAN connection.  This will prevent it from sending any traffic if the VPN goes down.

 Go to Firewall/Rules/Floating

• Action: Block
• Quick: Checked
• Interface: WAN
• Direction: any
• Address family: IPv4
• Protocol: Any
• Source: Single host or alias / [set local IP address of host here i.e. 192.168.1.100]
• Destination: any
• Description: enter any description here [i.e. "Block this IP from using non-VPN WAN"] 
• Click "Save"
  

Obvious notes:

-  This only really works if the machine in question uses a static IP address.

-  You can define multiple rules for different devices.

-  You can set the rule to block a range of IP addresses by using "Network" instead of "Single host".

This approach does not use policy-based routing and does not decide which machines use the VPN and which don't.  It just forces all traffic from a machine through the VPN, else the traffic gets blocked.

Speed change between Netgear R7000 / DD-WRT and Core I7-7500U / pfsense routers using PIA AES-256

This was a quick test only, using a popular torrent client.  

The Netgear is a recent (faster) example running the latest DD-WRT.  The pfsense box is an eBay i7-7500U special with the latest pfsense.

Speeds are peak speeds through Private Internet Acccess (PIA) using AES-256 / SHA256 on their "Next Gen" network.  There were no changes to the rest of the setup between the two trials.

Results:

• Netgear: 4 MiB/s 
• i7-7500U: 38 MiB/s

That's almost a 10x improvement.

Note I couldn't get these speeds using all torrents, as some of the sources are limited. 

However, I know that the Netgear can't exceed 5 MiB/s no matter what, while the i7 definitely can do 38 MiB/s.  It's possible the i7 might be able to go even faster.

From this, it does appear obvious that the Netgear is quite limited with respect to VPN crypto. 

Obviously the i7 is vast overkill.  I got it since the price difference between the i3 and i5 was nominal and I really only feel like doing this once.  See here for tips on buying such a box.

My experience with Montana Mailbox / DYK Post

First parcel, no issues.  Took a little while to get the incoming ticket, but didn't think anything of it - I figured the delivery had been slow, and I didn't care.  Picked it up at DYK without any issues.

Second parcel was Amazon, so I had a delivery date.  It took Montana Mailbox 7 working days (12 calendar days) to issue the incoming ticket. 

I wanted the parcel earlier, so I sent an email 4 working days after delivery, to see if Montana could expedite it.  I never got a reply.  I was hoping to get at least a "Sorry, we can't help with that", but nada.

MM is undoubtedly big, but I can't see them having a 7-day incoming queue.  So they obviously prioritize commercial traffic over individual parcels, meaning one-off packages will take however long they take.

It then took another 9 days for DYK to just pick it up, plus an additional 2 days to get it to the correct office.  So about 15 working days, or 23 days total, until it arrived.

Again, DYK is not likely to have a 9-day queue, especially when they pick up every day.  It may be the package got held up in Customs, which can happen to any package.

So, while the Montana Mailbox / DYK Post teamup seems a good service, do NOT use it for anything time-sensitive.  Or, if you do, allow at least 10 working days after delivery for Montana Mailbox to issue your incoming ticket, and another 10 working days for DYK to have it ready to pick up.