[Thebigman15]

I'm having a slightly different problem, I cannot activate streaming through the video.me no matter how many times I do it through their website. Once I activate it it says that's me but when I try to watch something through the video.me it doesn't let me. My ip address on the website is 2a02:0c7d:4e92:6500:c5a4:baec:8b75:3ce9 which I thought was a little strange and on kodi (with a wired connection) it's the usal 192.***.*.**. Any help would be appreciated

[Mamba123]

I'm having a slightly different problem, I cannot activate streaming through the video.me no matter how many times I do it through their website. Once I activate it it says that's me but when I try to watch something through the video.me it doesn't let me. My ip address on the website is 2a02:0c7d:4e92:6500:c5a4:baec:8b75:3ce9 which I thought was a little strange and on kodi (with a wired connection) it's the usal 192.***.*.**. Any help would be appreciated

First of all, obviously your internet connection is done with IPV6 already (thats the 2a02.... stuff), whereas KODI is only capable of talking IPV4 (yet) (thats the 192.x stuff). They dont go together at all.

But, there is a deeper problem hidden in your request. You try to access video.me you say, a site run by godaddy.com which is also on V4 only. BUT! that video site does not have videos at all! they just hand you over to Youtube! And Youtube is V6 already, so you make the most modern connection possible.
But this maybe just your browser fooling you! Your browser (and obviously your OS too) is capable of talking both protocols, you dont even notice the switching. Kodi always stays on V4, it cannot switch, but of course Youtube is also still running V4. So, it SHOULD WORK!.
It seems that Kodi does not like the handover from GoDaddy to Youtube. Try to access a Youtube video directly and see if it plays.

[Thebigman15]

Thanks for the reply!
I've tried to access YouTube both through kodi and through the android app on my box and both play fine

[mveras1972]

I wish people would stop saying this is a cosmetic problem. There are real network issues here due to this bug in Kodi, which is much older than what I thought. In my case, I just installed Kodi 17 Beta 3 on my new Amazon FTV using ethernet rather than WiFi. As a result, I cannot SMB into my home server from Kodi, whereas from ES Explorer and other apps, the FTV connects to my SMB share with no problems. So I am able to isolate this bug to Kodi.

As a computer technician, I can understand how applications, if they have a bug, can refuse to use the correct network interface. The Amazon FTV has two network interfaces, one is Wireless and the other one Wired, and each has their individual MAC address and can have their own IP address. When you disconnect the Ethernet cable, the Amazon FTV automatically switches to WiFi mode, and when I do this there are no issues with Kodi. Kodi reports the correct IP, and SMB shares from local servers work fine. However, when connecting an Ethernet cable, the FTV stops using WiFi automatically, and it self-assigns the 192.168.49.1 address everyone is seeing to the WiFi interface. From the AFTV interface, you cannot see this IP address because it hides it because it is not supposed to be used. However, the WiFi radio on the AFTV is still active and can be detected by Kodi. Apparently, Kodi has a preference for using WiFi over Ethernet. Maybe this is based on hardware enumeration by the Android OS in the AFTV, and so Kodi gets confused and tries to access the network using the wrong interface (WiFi) because AFTV self-assigns an IP to the WiFi interface.

The first time I noticed this was a network issue was when I tried to add a new network source in the Kodi file manager, and using the server name, it could not find it, but if I used the server's IP address, it found it. When we look at our Kodi network settings, it has an IP of 192.168.49.1 IP address and no gateway, however it has a correct DNS server IP. That explains why the problem happens. It makes perfect sense that if you are coming from a 192.168.49.x subnet and want to connect to something in the 192.168.1.x subnet with no gateway address, then the destination IP is not found. From the Amazon FTV interface, you can match the MAC address reported by Kodi, to the WiFi interface in the Amazon FTV network settings. The MAC address for the Wired connection of the AFTV is all I can see in my network router, but that MAC address is nowhere to be found in Kodi, meaning that Kodi is just using the wrong interface, which means network problems. So this is NOT a cosmetic issue. This means that Kodi is insisting on using the WiFi interface, which has no real connection to the rest of the network, and therefore we have these problems. This is why we can declare with confidence this is a bug in Kodi. An app should be able to manage its way to use the correct network interface if the first interface is not working correctly, or at least offer some menu option to allow the user to choose the correct interface.

Since Kodi doesn't offer that option, the solution here would be to somehow turn off the WiFi radio completely on the AFTV so that applications like Kodi don't get confused and only see one network interface, the Ethernet, and skip the WiFi interface entirely. Now, how to do this? The Amazon settings have no way to turn off the WiFi radio from the UI. However, I bet there must be a way to do this if we telnet or SSH into the AFTV via the command line. After all, this is Linux at its core.

I have no interest in using WiFi on the Amazon FTV just because Ethernet delivers much more consistent video streaming performance. We know the remote uses Bluetooth so hypothetically it should not have an effect if we turn off the WiFi radio. The Bluetooth and WiFi MAC addresses should be different. However, some wireless chipsets have both WiFI and Bluetooth in the same chip, and if we turn off WiFi, it can also turn off Bluetooth rendering the remote useless. If that's the case, one can get a Microsoft Media Center remote, which comes with a IR receiver and connect that to the AFTV USB port, and use the Media Center remote to operate the AFTV.

I have some homework to do and if I discover solutions from what I explained here, I will definitely post an update.

[Koying]

As a computer technician

Well, all the computer technicians I know would know that if you can reach your samba server by ip address, the ip setup is correct

[fritsch]

As a computer technician

Well, all the computer technicians I know would know that if you can reach your samba server by ip address, the ip setup is correct

+1

[Koying]

For all the "computer technicians" around, I suggest to read about the OSI layers: https://en.wikipedia.org/wiki/OSI_model#...OSI_layers

IP is layer 3
TCP is layer 4
Samba would be layer 7

[Martijn]

Layer 8 is where the usual errors are

[stefansaraev]

I propose removal of that "network" tab in system info dialog, as in some limited cases, misleading info may be present, so misleading that users believe it's a "real bug" and that kodi "insists" on using something.

another option would be to make it show ALL configured interfaces (ones that have an ip address), like pvr info is implemented when multiple pvr clients are in-use.

EDIT: I can't implement 2nd, but I volunteer to do the removal, and create a python addon to show user's per-interface ip configuration.

[Koying]

Well, the info is interesting in the 95% of the cases where a single interface is active at the same time.
IMHO, the proper fix would be to read the routing table and check which interface has the default route going through...

PS. IMHO, some users making wrong assumptions is not a proper reason to remove functionality

[kinggo]

PS. IMHO, some users making wrong assumptions is not a proper reason to remove functionality

This.
So apparently, this is mostly FTV issue. Thread starter has bravia. I also have bravia and don't have this problem. Never did with any version of kodi/SPMC. I use wifi only on my TV and every instance of kodi always picked that one and never had any problems with access to any of my shared drives/folders.

@mveras1972
There's more than one way to get host name from IP and it's not that they are all reliable and work well together. And what works best on windows might not work at all on linux or something else. And the fact that you can reach server with IP address but not by the name just confirms this.

[stefansaraev]

Well, the info is interesting in the 95% of the cases where a single interface is active at the same time.
IMHO, the proper fix would be to read the routing table and check which interface has the default route going through...

PS. IMHO, some users making wrong assumptions is not a proper reason to remove functionality

not that I disagree, but you know that you can have default route via more than one router (via same or different interfaces). this will soon get very ugly.

the propper fix would be to show all configured interfaces, and whether they have default rout or not.

[Koying]

not that I disagree, but you know that you can have default route via more than one router (via same or different interfaces)

Not sure what you have in mind... There is one and only one *default* route, which is 0.0.0.0 with lowest metric.
All the other routes are not "default" per definition.

[stefansaraev]

lowest metric does not make the route "the only" default. and you can have multiple default routes with same (lowest) metric. you can also have multiple routing tables (connman, anyone?)

however.. it's not the app's job to care about it, if you want to show some decent info, show it all, or show nothing

[mveras1972]

Stefansaraev makes a great point, and this is exactly what I am observing. Since I re-read my post I realized I made some mistakes. So I need to make some clarifications and I apologize for the confusion. What I said was that I can reach the SMB using IP but not the name using ES Explorer, not Kodi. That means one application follows the correct route and the other one doesn't. Now, for ES Explorer, this may sound like a DNS issue, but it is interesting how Kodi cannot reach the server even by IP. Sorry for the confusion. My bad. It was a long post and I was in a rush. Also, Kodi seems to be able to reach the internet with no problem, but not the local server. This is one more evidence pointing to what stefansaraev explained about different requests taking different routes. Makes perfect sense.

Also, I realize applications don't talk to lower layers in the OSI model. My network engineering class was over a decade ago so my apologies if I'm a bit rusty. However, if I'm not mistaken, trying to bind to * is part of the problem here because the AFTV is making a mess trying to manage packets to the right interface. If only there was a way to specify where you can bind, this would work around the problem. Even though this is not the responsibility of the application, but it is possible to have a workaround available. Also, the AFTV doesn't give a way to turn off the wireless interface which doesn't help either.

I did some research and found that if you turn off the wireless on AFTV, I guess via SSH or Telnet or whatever, it also turns off Bluetooth which is a problem for the remote. Atlso, wireless turns itself back on after a reboot. They certainly don't help, but they are not about to give a damn about this either since Kodi is not a supported app. For now, I have disconnected the Ethernet cable until I can figure out a solution. Kodi seems happy when wireless only is connected.