2020-02-17, 08:01
try to increase the lease-time with your router ... that really looks like your shield disconnects.
2020-02-17, 10:22
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.
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
(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.
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
(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:01
(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.
If I'm understanding you correctly (that assigning a static IP address in the router is what gives it an unlimited lease) then I don't think it will fix anything here as I've always assigned ALL my regular devices their own local permanent IP addresses. I regularly connect to it via SMB://192.168.1.6 here. It's always that address.
2020-02-18, 03:08
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.
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
(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.
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
(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.
2020-02-18, 05:23
(2020-02-18, 04:34)Pirivan Wrote:I'll give it a try when I get back.(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.
2020-02-18, 08:16
Mea culpa, it looks like the static IP did not completely resolve the issue. It worked through several full length 4K movie playback tests, which it NEVER had before so I took that to mean the issue was resolved (it does seem to be improved in my defense, the issue may be less frequent). Then, while watching a TV show episode it quit some 10 odd minutes in. I immediately checked the Kodi and Asus Router logs.
Router log:
Feb 17 20:05:07 WLCEVENTD: eth2: Assoc <Shield TV MAC>
Kodi log:
2020-02-17 20:05:03.786 T:21509 ERROR: Read - Error( -1, 103, Software caused connection abort )
So, the behavior has changed slightly. After setting a static IP, there is no more DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPSOLICT process in addition to the WLCEVENTD message. I did a bit of research and I believe that WLCEVENTD is technically unrelated to DHCP. According to the developer of Asuswrt (the slightly modified stock firmware I run on my router) WLCEVENTD is: "A daemon Asuswrt runs to detect wireless client connecting/disconnecting"
So, back to square one in some ways. Basically all I know is that the ShieldTV is disconnecting from wireless very briefly and that causes Kodi playback to halt. I did some quick research and have the following possible solutions to investigate based on searching for ShieldTV + Asus router wireless issues:
Router log:
Feb 17 20:05:07 WLCEVENTD: eth2: Assoc <Shield TV MAC>
Kodi log:
2020-02-17 20:05:03.786 T:21509 ERROR: Read - Error( -1, 103, Software caused connection abort )
So, the behavior has changed slightly. After setting a static IP, there is no more DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPSOLICT process in addition to the WLCEVENTD message. I did a bit of research and I believe that WLCEVENTD is technically unrelated to DHCP. According to the developer of Asuswrt (the slightly modified stock firmware I run on my router) WLCEVENTD is: "A daemon Asuswrt runs to detect wireless client connecting/disconnecting"
So, back to square one in some ways. Basically all I know is that the ShieldTV is disconnecting from wireless very briefly and that causes Kodi playback to halt. I did some quick research and have the following possible solutions to investigate based on searching for ShieldTV + Asus router wireless issues:
- 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
- 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)
- 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/for...ate-done-/
- https://www.reddit.com/r/ShieldAndroidTV...ters_wifi/
- 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
- 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/for...onnecting/
- Suggested on this massive Nvidia forum thread: https://www.nvidia.com/en-us/geforce/for...onnecting/
- 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/for...tfix-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.
- https://www.nvidia.com/en-us/geforce/for...tfix-imag/
- 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/releas...ble.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)
- https://www.snbforums.com/threads/releas...ble.61694/
- 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.
- 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.
- 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).
- 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).
2020-02-18, 08:51
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?
2020-02-18, 08:55
(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?
Hi Fritsch, really appreciate the feedback but yes, I did test with NFS and that also failed (it had a slightly different error message):
2020-01-05 23:16:38.649 T:29650 ERROR: Read - Error( -5, nfs_service failed )
I am pretty convinced that it's a wireless networking issue between the latest Shield TV firmware and various Asus routers (possibly a specific broadcom chipset used by a variety of wireless routers).
2020-02-18, 14:45
Given it started quitting here with the last firmware update, I'm still suspicious they changed something that screwed it up. I clearly remember CEC causing this before, but they've changed their CEC menu. There is no total "OFF" button, just individual sliders. Perhaps it's still interfering in some undocumented way?
2020-02-19, 09:29
FYI to avoid spamming everyone, I am have been editing my post from yesterday where I was listing possible fixes with the results of those tests. I will continue to do that but in summary so far:
- 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.
- 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)
