Have you tried rebooting? It looks like My OSMC may have got stuck configuring your connection. The output of ifconfig after a reboot may yield some clues. Make sure your system is up to date.
What version are you on? 2016.12-1 is the latest version.
It tries to configure itself for about 3 minutes, then settles up with a 169.254.238.138 / 255.255.0.0 (which are probably defaults for no connection…)
Yes. Updated, rebooted, reinstalled from scratch and repeated the whole process over.
Yes. Tried different ports, different cables. Raspberry PI2 and 3 with OSMC are working on this cable without problems. Also any other device I tried to plug in. The cabling in walls is CAT7, the patch cable is higher quality CAT6.
The behavior is the same regardless of port it is plugged in (tried both switch and router).
However it also looks like the link is going down sporadically. There can be a few reasons for this:
Bad patch cable
A conflict on the network
Some software conflict on the device itself
Hardware issue
Without knowing more about your network, it’s a little hard to speculate what the issue may be, but I am sure we can get to the bottom of this:
Have you experienced any other problems with the device? Is the plug connected directly to the wall? Sometimes if a device isn’t getting enough power, the network can drop in or out. But if this was the case, I would expect to see this with WiFi as well.
Does running the following commands help? sudo rmmod am_net8218_osmc && sudo modprobe am_net_8218_osmc. This will reload the Ethernet module and reset the PHY.
Have you installed any other software on your device?
How familiar are you with the command line and networking? There are a couple of things that we could explore. I would start by running a standard cat5e from the Vero 2 to your Raspberry Pi. You don’t need DHCP etc, but if you can just see if the activity lights stay on and if the link stays up in dmesg, then it may give you some clues.
Yes, saw it myself. But I do not know what it means.
I would leave this one out. Other devices are working on the same cable.
May be, but I find it not probable, because Raspbery Pi 2/3 with OSMC are working well (each one, including vero2 has unique name).
Can’t elaborate on those two, as I am not linux savvy. Even if it was a hardware problem, I would not know where to look.
Nope, did not see other problems.
rmmod: ERROR: Module am_net8218_osmc is not currently loaded
Nope, clean install.
I am a programmer by occupation, so command line will not scare me. Networking is not my field, but I do know some basics. I am up to try to solve this, but I will need precise instructions. With the RbPi setup I am at lost with “if the link stays up in dmesg”… What should I look for?
19:55:52 T:2825503728 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <class 'dbus.exceptions.DBusException'>
Error Contents: org.freedesktop.DBus.Error.UnknownObject: Method "SetProperty" with signature "sv" on interface "net.connman.Service" doesn't exist
Traceback (most recent call last):
File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/networking_gui.py", line 386, in onClick
self.handle_wired_selection(controlID)
File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/networking_gui.py", line 1000, in handle_wired_selection
osmc_network.apply_network_changes(self.current_network_config, self.internet_protocol)
File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/osmc_network.py", line 143, in apply_network_changes
service.SetProperty('Nameservers.Configuration', dbus.Array(dns, signature=dbus.Signature('s')))
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Error.UnknownObject: Method "SetProperty" with signature "sv" on interface "net.connman.Service" doesn't exist
-->End of Python script error report<--
The error above is occurring because the network seems to be dropped in and out, which is causing problems when OSMC tries to assign an IP address to the adapter.
Can you answer these few questions?
If you have a spare SD card (8GB or larger), you could quickly grab the Android image from Download - OSMC and see if the Ethernet works here. This would probably rule out a software issue quite quickly. The Android image runs off the SD card and won’t erase OSMC off the internal storage.
I’m guessing that when the link is going down, the lights are going off on your switch / router. It’s worth checking that, and if it’s the case, plugging a patch between the Pi and Vero 2. The lights should stay on.
Sometimes it does not response to remote (and wireless keyboard) in realtime, but buffers the input. And the it plays it rapidly at a later time.
Yes, it is. No power surge protection, no UPS, no frequency filter…
Tried this, but it does not seem to boot off the SD card. At least I can see no difference (System info / Summary / Operating system: OSMC 2016.12-1, kernwl Linux 3.10.104-8-osmc). The wired network behaves the same.
It almost never registers with the router. Rarely there is a message in the router’s log about assigning IP to vero2’s MAC, but it stays in the list of connected clients only for a few seconds. That is when vero2 decides to use some 169.254.. address and never recovers.
I have tried the Pi vs vero2 direct link. The lights seems to lit the same way (one is amber, the other one green and blinks from time to time.) Since you did not specify what to look for, I tried this (about 5 minutes after vero2 boot):
osmc@vero2:~$ dmesg | grep eth0
[ 9.707956] eth0: PHY ID 02430c54 at 0 IRQ -1 (0:00) active
[ 11.135159] eth0: opened (irq 40).
[ 11.135291] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 11.778803] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
The port does not matter, happens with any. But strangely not when booted to android.
Did that, as much I can tell, the wired nic works well in android. But tested only in web browser. I do not know how to browse network for video files in this environment.
I tried it at my parents place (=other city, other router, other cables). Did not work either.
Next I tried to completely reset settings on my router. After that I noticed in router logs, that vero2 tries to get IP every 3 secs or so. It just seems to be not happy with the answer…
Jan 2 19:51:54 dnsmasq-dhcp[2827]: DHCPREQUEST(br0) 192.168.1.9 08:61:60:11:26:45
Jan 2 19:51:54 dnsmasq-dhcp[2827]: DHCPACK(br0) 192.168.1.9 08:61:60:11:26:45 vero2
Jan 2 19:51:58 dnsmasq-dhcp[2827]: DHCPREQUEST(br0) 192.168.1.9 08:61:60:11:26:45
Jan 2 19:51:58 dnsmasq-dhcp[2827]: DHCPACK(br0) 192.168.1.9 08:61:60:11:26:45 vero2
Jan 2 19:52:02 dnsmasq-dhcp[2827]: DHCPREQUEST(br0) 192.168.1.9 08:61:60:11:26:45
Jan 2 19:52:02 dnsmasq-dhcp[2827]: DHCPACK(br0) 192.168.1.9 08:61:60:11:26:45 vero2
This sounds like a software issue. We recommend the remote receiver is placed in the back port. If it is in any other port then the issue is expected (as they are configured differently). If you can take a small video of the problem with the receiver in the back port then we will look and resolve the issue.
That’s fine. If you can browse a few websites without any problems, then it sounds like it is working. But I’m not sure why you have problems under OSMC at all.
Can you check ifconfig shows the MAC on the bottom of the device?
I have one idea, and I’ll produce a test build to confirm if you’re happy to try.
Terribly sorry – this should all simply work, but sometimes we bump in to some stranger network environments.
Normally I would suspect some hardware problem, but you have reported that the Android release is not causing problems for you.
Android uses a different Ethernet driver, one that I have planned to transition to for a while, as it does provide better performance, and it is officially mainlined, which means that it is supported upstream in the Linux kernel.
I would be very interested in your feedback regarding this driver. Currently you will be first to test this new driver, which may give better speeds. I will get some other users to test it as well.
If you still have problems, then I would suggest you try plug the Vero 2 in to a network at work or a different location. Of course, if there are still problems, we will replace the unit for you.
I am at my parents this weekend, but for now it seems to be working. Vero2 can now get IP via DHCP, and the link does not drop (tested by leaving open SSH session). I will do more tests at my place on Sunday.
Thank you for taking time to report back. I am glad that things seem to be improved now, but I will await your further feedback on Sunday.
The Vero 2 however should have worked for you out of the box. I have arranged for a credit to be applied to your account and this will be explained to you shortly.
Lastly, can you later confirm that the remote works as expected when plugged in the back USB port? You will need to reboot after reinserting the receiver, so you may prefer to do this after shutting down and before booting again