Your box is from a vendor who saved pennies by not securing a unique MAC address range for their products. As a result the NIC in your box does not have a programmed (fixed) MAC address. Under Android the kernel has been hacked to assign a static MAC address (normally unique to the 20k or so boxes in the production run). Under Linux the kernel hack doesn't exist. If you're lucky you get a different static MAC. If you're less lucky the kernel will generate a random MAC that changes on each boot. If can be "fixed" with a udev rule or systemd service that corrects it during boot. There's some threads on the topic in this forum if you search for them.
Posts by chewitt
-
-
Not even remotely possible.
-
Updates are enabled, but we only publish for official images. What hardware (and image) are you using?
-
It's really quite simple: inputstream.adaptive can leverage the widevine libs if present. On Android where some devices have L1 certificates this allows full hardware decoding of the stream. On Linux there are no open devices with L1 widevine support so inputstream.adaptive pretends to be a web browser with an L3 certificate that most content providers allow up to 1080p streams for. Some providers allow up to 720p streams. Some providers encrypt both video and audio (Netflix is one) while others only encrypt video which results in a lower decryption load; and on low-spec hardware this can be the difference between coping and not-coping with 1080p.
-
What's the use-case for needing LE devices in a swarm?
-
The police call it "eliminating suspects from your enquiries" .. I wasn't expecting a result, but wanted to know either way. The changes prevent the issue where we attempt (and never remove) ipv6 servers from the list of possible servers to use in addition to ipv4 servers.
-
You're better off asking in the Kodi forums where content add-on developers hang out.
-
OSD is a core Kodi function, but it is skinnable. So the dirty hack is to create a custom skin that removes the OSD, but then you remove all of the OSD and not just the start bit. To change things so there is no OSD at the start (but overall retaining the OSD) would require core code changes.
-
Discussion on how to bypass GeoIP and break service provider TOS will put this thread on the wrong side of forum rules.
-
I am 100% confident that widevine content is software decoded. There may be some other issue, but further diagnosis needs a debug log.
-
Anything that you play via libwidevine is software decoded so you're dependent on the capabilities of the CPU and most ARM boards are basically weak in this area. You might find 1080p is too much and 720p or even SD are the maximum possible.
-
-
What WiFi chip is in the device. What driver is being used?
-
Code
cat /storage/.kodi/temp/kodi.log | paste^ our in-build paste function to ix.io has a 1mb limit
-
but it does not work on restart, just on start.
If restart = cold start then autostart.sh will be run. If restart = wake from suspend it will not be run, because autostart is a boot script and waking a suspended system is not boot. Your current script forces the entire boot process to stall for 5 secs. It would be better to (background)& the mount task so that boot can continue normally. You can look at using systemd .power functions in /storage/.config/system.d/ to schedule actions around system suspend and wake events.
-
We expect behaviour in the latest S912 image to be slightly different as we switched from the ARM mali_kbase driver to the new (meaning new bugs) panfrost DRM in-kernel driver which has now reached broad parity with the ARM driver. Memory behaviour seems to be better. Overall stability seems to be about the same, i.e. there is still crashing but the crashes are different.
-
kodi.log .. I want to see the output of the python add-on when it fails
-
Connman stores connection information against a service name which includes the wireless interface MAC address. I have a hunch the WiFi chip does not have a fixed MAC address (i.e. MAC changes with each reboot) which means the previously configured connman service is no longer valid and a "new" configuration (for the new MAC) must be created .. and if you reboot again it will be lost again (rinse/repeat ad infinitum).
To confirm the hunch .. check the MAC address between reboots.
