You can't reach the Network Connection because of access problems.
You can't reach the Network Connection because of access problems.
I am still trying to get the IP addresses, so I have been busy. The Beelink devices are the ones you need, but don't read the description because CoreElec is on an SD card and completely bypasses the Android OS. It works over WiFi or Ethernet, and in Kodi it automatically finds the ethernet connection. If I want to use WiFi, Kodi has a way to turn it on and put in the password.
I can reboot back into Android, but that would only be for testing because whatever changes I make there don't affect when I reboot off the SD card. Scraping is irrelevant; even if I don't scrape, it drops the connection. So, what's interesting? I'm wondering if I might have had this set up before, which explains why I knew about that option... the option to wait for network connection before booting into Kodi.
I let it sit turned on for 8 hours and tried again; still connected. Rebooted and still connected. It's been running for 24 hours now, and my family is watching something on it. So, seems like having it wait 10 seconds at startup to check the network connection fixes the issue. Though, even if that solves the problem, I guess I'm wondering why do I need that option enabled?
My main HTPC1 doesn't need that extra option because my router is directly connected via ethernet cable with a six-foot cable. Even without the delay, it still says "connected" and when I tested the mapped drives failing connection, I used the YouTube app and the video played perfectly. So it was indeed connected regarding IP wise... Interface: 192.168.1.6 --- 0x6 (PC1) Internet Address Physical Address Type 192.168.1.1 cc-be-59-89-6b-15 dynamic 192.168.1.16 70-85-c2-28-c0-d0 dynamic (PC2) 192.168.1.32 30-fd-38-96-5d-4a dynamic (NAS) 192.168.1.38 52-34-64-96-80-06 dynamic (HTPC1) 192.168.1.41 c4-98-5c-eb-b3-20 dynamic 192.168.1.78 52-a2-f8-d3-11-7c dynamic 192.168.1.255 ff-ff-ff-ff-ff-ff static 224.0.0.2 01-00-5e-00-00-02 static 224.0.0.22 01-00-5e-00-00-16 static 224.0.0.251 01-00-5e-00-00-fb static 224.0.0.252 01-00-5e-00-00-fc static 239.255.255.250 01-00-5e-7f-ff-fa static 255.255.255.255 ff-ff-ff-ff-ff-ff static
Connection dropped: So, it seems that waiting 10 seconds when starting up fixes the network issue. Maybe the ARP table is causing this problem. Which IP or MAC address does HTPC2 have? Is HTPC2 even listed somewhere else? You can use a MAC address to guess what makes a device from a certain manufacturer by looking at the first three numbers of the address. But checking 52-34-64-96-80-06 didn't find any maker (Beelink?). There are no other MAC addresses starting with those exact numbers... Unfortunately, manufacturers don't always follow rules and even reuse MACs sometimes. There are websites online to help identify makers by device MAC address. Maybe 192.168.1.78 52-a2-f8-d3-11-7c is HTPC2? I think Beelinks, NAS, and ROUTER2 should have static IP addresses set via the main router (ROUTER1). Those assigned static IPs are outside the range of DHCP addresses allowed to the main router. And there are also specific static IPs reserved for each device by its MAC address (Plus the MODEM and ROUTER2 both having any DHCP functions turned off as I understand it). If the NAS and Beelinks' IP addresses keep changing with the DHCP method, then other network devices need time to find them again and update their ARP tables accordingly. By the way: https://www.geeksforgeeks.org/how-addres...arp-works/ https://www.ipxo.com/blog/address-resolution-protocol/ There are other similar explanations and tutorials available too. Overall, it can take a long time for network connections to restart after something goes wrong, especially if some of or all of the devices get different IP addresses because of that change. And if things keep changing during that update time, everything could start over again... Specifically, what does Kodi do when it doesn't find a specific device or not immediately find it because the target's IP address changed? Because "time" seems to be a factor and I have no way to test this with Kodi etc., so I need to wait for others regarding how ARP works (or doesn't work) in this current environment. There are lots of moving parts here.