(2020-02-17, 10:22)Pirivan Wrote: I did not not want to post before I felt confident in my results but after my previous post where I noticed a possible wireless/DHCP related issue by comparing the router and Kodi logs when the exit occurred, I did some further testing.  I assigned a static IP to my Shield TV (using the Shield UI, I just assigned the static DHCP lease I had set on my router already as a static assignment on the Shield wireless NIC) and then played back an entire 4k movie without any issues.  I then replicated this test a second time, again 0 issues.  That has never happened in Kodi (only MrMC) since I setup Kodi on the Shield.

I feel pretty confident in saying that my issue is finally resolved.  Even though the DHCP lease time on my router is set to 24 hours, the Shield is doing something bizarre when on WiFi causing it to lose the connection and then attempt to get a new lease/renew the DHCP lease every 1-2 hours (not sure about the precise interval).

One caveat here is that I had some completely unrelated 2.4Ghz WiFi issues that started on Friday that I have been troubleshooting at the same time, so I DID also set my router to not dynamically set the channel  and instead statically set it to 11/20mhz width for 2.4Ghz and channel 149 80mhz width for 5Ghz (ShieldTV is connected to 5Ghz).  So, technically I did make two changes, the static IP and set static channels/width. However, I tested previously with static wireless channel settings WITHOUT the static IP and that did not make any difference (still random exits); the static IP was the key.  I am pretty confident that the wireless changes, moving the Shield around physically etc. were not related to the fix, only the static IP was.

Thanks for the feedback as well fritsch, (your hard work on Kodi is much appreciated) we were on the same line of thought!

I will continue to monitor the situation and update if it re-occurs but hopefully I am all set and this solution is helpful to someone else in the future.

(2020-02-17, 22:58)VonMagnum Wrote: I'm actually unable to access the equipment right now (trip).  But how does MrMC play into that equation?  Isn't the Shield's WiFi leased by the device not the program?  I don't recall manually setting lease times before.  I won't be able to look at it on my Asus router until I get back.  Perhaps the "freezes" were also leasing errors, but if they were buffered enough, it reconnected before it froze or stopped? 

(2020-02-18, 02:18)Pirivan Wrote:

(2020-02-17, 22:58)VonMagnum Wrote: I'm actually unable to access the equipment right now (trip).  But how does MrMC play into that equation?  Isn't the Shield's WiFi leased by the device not the program?  I don't recall manually setting lease times before.  I won't be able to look at it on my Asus router until I get back.  Perhaps the "freezes" were also leasing errors, but if they were buffered enough, it reconnected before it froze or stopped? 

If I understand the situation correctly, I think it's likely that the WiFi disconnects/DHCP lease renewal was occurring when using MrMc as well.  However, MrMc was masking the issue because it uses a different SMB client which seems to handles a brief network drop/interrupt more smoothly (perhaps by having a larger buffer?) than the one currently implemented in Kodi. 

To clarify, I didn't change my lease times (24 hours) because the ShieldTV wasn't respecting the lease timer anyhow, it was doing something bizarre on wireless more often than 24 hours, I just assigned it a static IP on the Shield itself to prevent it from ever requesting a new lease. 

(2020-02-18, 03:08)Pirivan Wrote: What I had setup on the Asus router was a DHCP reservation, which is not quite the same thing as a static IP address.  The Shield TV still renews the DHCP address lease, it just always renews it with the same IP and the router will never give out that DHCP address to any other client because it 'knows' it is associated with the Shield TV MAC address.

What I had to do was ALSO assign the Shield TV wireless interface a static IP that was equivalent to the static DHCP reservation I was using for it on the router.  If I understand correctly, this prevents the ShieldTV from ever trying to renew the lease, which it was doing on bizarre intervals (not ever 24 hours), causing the network interruption.  Alternatively, you do not have to use DHCP reservations on the router at all.  You could assign your ShieldTV (on the device itself) a static IP in your local subnet but OUTSIDE of the DHCP pool, that should work as well.  I simply chose to statically assign the Shield the DHCP reservation I had setup for it on the router.

Are you assigning static IP's locally on the devices or are you setting up DHCP reservations for the devices on the router (as I was)?  If you have been assigning static IP's for each device within their configuration UI (aka the Shields wireless network settings) then this may not be a fix for you as you have already implemented it. 

I will continue testing but the issue so far appears to be completely resolved for me with this change.

(2020-02-18, 04:24)VonMagnum Wrote: I guess I don't know how to do what you're talking about offhand and can't look at it for some time.  Where can you assign that within the Shield itself? 

(2020-02-18, 04:34)Pirivan Wrote:

(2020-02-18, 04:24)VonMagnum Wrote: I guess I don't know how to do what you're talking about offhand and can't look at it for some time.  Where can you assign that within the Shield itself? 

On the Shield: Settings -> Network & Internet -> <wireless network name> -> IP settings -> Static -> assign static IP settings (again I used the same settings it already had from the DHCP reservation)

Note, for some reason getting the Android TV interface to 'move forward' after inputting an IP was problematic when using an Android remote control application (scrcpy on my PC), it doesn't like to let you 'accept' what you input to move to the next field and I had to use the my physical remote/wireless keyboard to click OK. 

Also, when I tried to set this the first time it told me that the IP settings weren't valid but when I attempted it again immediately using all of the same IP address/subnet/gateway/DNS information, it accepted it and applied.  So, reattempt a few times if necessary and likely configure it using the actual Shield with a remote/keyboard rather than a remote control application like scrcpy. 

• Disable 'Live Channels' app on the Shield TV ->  ----EDIT---- It took  8 or so TV episode playback tests before it had the issue with the router/kodi log error.  Either this fix (or more likely the static IP fix) did help the issue a bit but did not resolve it
  • According to some users on the below lengthy Nvidia forums thread, the live channels app can fill up connections until Android cannot make anymore so you need to disable the app (you can't uninstall it)
    
  • https://www.nvidia.com/en-us/geforce/forums/discover/222443/network-randomly-disconnecting
    
• Disable Wi-Fi direct on the Shied TV  -----EDIT-----  This does not appear to be possible, so I will likely never attempt this fix as you cannot disable it without disabling Wi-Fi completely.
  • It looks like the Shield TV automatically sets up a local 5Ghz wireless network on the SAME channel used by the 5Ghz wireless network it is connected to for usage allowing the Shield TV remote and controller to connect
    
  • Apparently, ironically, this can cause 5Ghz wireless issues.
    
  • Unfortunately, I am not sure if you can ACTUALLY disable the Wi-Fi direct feature (which makes any Shield remotes or controllers not work) without completely disabling Wi-Fi on the Shield completely, which is pointless for trying to 'fix' the wireless disconnection issues
    
  • https://www.nvidia.com/en-us/geforce/forums/discover/223501/disable-wifi-direct-ssid-from-broadcasting-is-it-possible-update-done-/
    
  • https://www.reddit.com/r/ShieldAndroidTV/comments/8tgab7/can_the_nvidia_shield_influence_asus_routers_wifi/
    
• Disable MU MIMO and beamforming on the router ----EDIT---- Failed after 4 TV episode playback tests
  • Suggested on this massive Nvidia forum thread: https://www.nvidia.com/en-us/geforce/forums/discover/222443/network-randomly-disconnecting/
    
• Test NVIDIA Shield 2015 Second HotFix (32.5.205.110 deployed by NVIDIA on 2/14/2020): ----EDIT---- Failed after 2 TV episode playback tests
  • https://www.nvidia.com/en-us/geforce/forums/shield-tv/9/340245/20152017-shield-experience-upgrade-802-hotfix-imag/
    
  • This does have WiFi fixes relating to using 5Ghz DFS channels so it's slightly relevant.
    
  • Unlikely that this will resolve the issue considering that I am not using any of the DFS WiFi channels but I will test anyhow.
    
• Upgrade ASUS router firmware to 384.15 (latest available for ASUS WRT Merlin that is installed on my router) -> ----EDIT--- Failed after 5 TV episode playback tests
  • https://www.snbforums.com/threads/release-asuswrt-merlin-384-15-and-384-13_4-are-now-available.61694/
    
  • On this version of the firmware, you get 3 error messages in the logs instead of 1 and they are slightly more verbose:
    
  • Feb 18 23:04:25 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind <Shield MAC>, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
    
  • Feb 18 23:04:28 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth <Shield MAC>, status: 0, reason: d11 RC reserved (0)
    
  • Feb 18 23:04:28 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc <Shield MAC>, status: 0, reason: d11 RC reserved (0)
    
• Disable IPv6 on the router -> ----EDIT--- Failed after 3 TV episode playback tests
  • Some users have suggested that disabling IPv6 on the Shield is not good enough (I have done it already) and that it needs to be disabled on the wireless router itself if it is enabled.
    
• Purchase another router, considering Synology RT2600AC as a test
  • A bit of extreme solution but if I really think it's an issue between ASUS routers and the Shield TV this may fix the problem.  At this point given the number of hours I have burned trying to find a fix I am absolutely willing to throw money at the problem if it will actually fix it.
    
• Implement MOCA 2.5 adapters
  • This will cost some money and will require quite a bit of time to install the adapters, change around cabling (in addition to some research on how to set this up properly).  Given how much time it will likely take me to get this setup it's not my favorite option but I may consider it as it will likely 'solve' the issue by allowing me to bypass wireless completely (running Ethernet isn't really an option at this time unless I want it going across the floor).
    

Quote:2020-02-17 20:05:03.786 T:21509   ERROR: Read - Error( -1, 103, Software caused connection abort )

(2020-02-18, 08:51)fritsch Wrote:

Quote:2020-02-17 20:05:03.786 T:21509   ERROR: Read - Error( -1, 103, Software caused connection abort )

This could be the well known SMB issue since several months / years. Could you test with NFS?  

• Disabling Live Channels -> Playback still halts after X number of tests
  
• Disable WiFi Direct -> Not possible
  
• Disable MU-MIMO and Beamforming on the router on 5Ghz -> Playback still halts after X number of tests
  
• Test latest Shield 2015 hotfix -> Playback still halts after X number of tests
  
• Upgrade ASUS router firmware to 384.15 (latest available for ASUS WRT Merlin that is installed on my router) -> Playback still halts after X number of tests. 
  • However, this router firmware version DOES add some more verbose logging, so you get 3 log entries on the router when the failure occurs.  I don't think they really point toward any kind of specific problem or fix, it's just more verbose about the disconnect.
    

• Feb 18 23:04:25 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind <Shield MAC>, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
  
• Feb 18 23:04:28 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth <Shield MAC>, status: 0, reason: d11 RC reserved (0)
  
• Feb 18 23:04:28 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc <Shield MAC>, status: 0, reason: d11 RC reserved (0)