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
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
File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/networking_gui.py", line 1000, in handle_wired_selection
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__
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
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 osmc.tv/download 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
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.
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