Any ideas ?
Sharing logs from the box would be a good start. Ideally a Kodi debug log (set logging from advancedsettings.xml)
Any ideas ?
Sharing logs from the box would be a good start. Ideally a Kodi debug log (set logging from advancedsettings.xml)
Amlogic is top-dog at the moment due to a complete absence of competition but Amlogic devices are ~7% of our userbase and 80% of the support issues. Installation complexity is the root cause of a large percentage, but the prehistoric dog of a Linux kernel we are currently stuck with drives the remainder. RK development is progressing nicely and joint development is building a solid and sustainable foundation for Kodi based on Atomic DRM and V4L2 decoding. In comparison Amlogic are *miles* behind and although there is some work, the visible activity level is low. The long-term plan is to drop amcodec support in Kodi, so they either need to pick up pace and show progress or there is a significant risk they are the only SoC/GPU vendor holding things back. That would mean we get to make a decision on whether to throw Amlogic support under a bus and move everything else forwards, or continue with something that "works" but has many unresolved (and unresolvable) issues that drive most of our support traffic. It's not exclusively my decision, but I'd currently describe it as a simple decision.
No idea, but we're not going to debug Linux mint issues here. It's really not our forté.
It would be more appropriate to ask for Tvheadend (on Windows) support in the Tvh forum. People here have experience with our own Tvheadend server (on Linux) which is not comparable. In future please also pay more attention to the formatting of your post - it's basically unreadable.
What version of Ubuntu?
So it worked?
I'm not too interested in adding the txt files to our main distro as the driver-named file is not enough and I'd be concerned that the brcmfmac-sdio named files will conflict with other brcmfmac devices. I'd ask you to test a current milhouse release as well, as those will have newer kernels with newer versions of the brcmfmac driver. Plan C .. you need to learn how to self-compile an image to repeat the process I did (which is trivial).
The main Kodi DVB maintainer asks that you update to a Leia build and retest before filing trac tickets against Krypton for two reasons:
a) Krypton is a dead codebase so nothing will ever be fixed there
b) There are lots of DVB issue fixes in Leia so there's a good chance it's already been addressed
We used the latest patchset from the Pi Foundation folks at the time the release was assembled. It's unlikely there will be further 8.2 releases so the next round of Slice updates will come with Leia. I'm not aware of anything specific for 10-bit support, but then I'm not the person on staff who deals with most of the Pi related things.
Clone skin files from /usr/share/kodi/addons to /storage/.kodi/addons/ then change the name of the skin (folder and in addons.xml) then restart and select your newly named skin. The files are now editable.
No idea how you add another menu item .. the default ones are generated from core code.
The LE column looks about right. I can't speak for anything else. You should also consider the underlying OS software. Is the box running on a current or recent kernel or some hacked up turd that's 5+ years old. When you factor that criteria in .. they all fail (and they should fail).
Publishing via Zeroconf is a Kodi thing that depends on the OS level Avahi service running which is enabled/disabled from LE settings. Check that it has not been disabled there first. Plan B .. backup and clean install then selectively restore things from the backup. If you do a normal restore you will just restore whatever cruft/issue is causing the problem too.
Drivers must be baked into the LE image for things to work - no addons are required. We support most (but not all) of the common USB wireless crap out there. As most cheap devices do not make it clear what chipset is inside, it's a bit of a dice roll when purchasing.
No, and this will not change for some time as the V4L2 graphics driver it will use (and support for that driver in ffmpeg/Kodi) is still being coded.
It might test your patience and sanity with bugs, but it will not "damage" the box. IMHO things are not ready for broad public testing yet.
In LE 8.2 the default connection will be SMB2 and most routers appear to be crap and only supporting SMB1, so try adding vers=1.0 to the options. If that still doesn't work also add sec=ntlm so it's not trying to use NTLMv2.
File is updated again - this time with the three files you shared. The two txt files appear to be the same file at different versions (similar but not the same content. Both appear to have references to hardcoded MAC addresses so there is no way we'd embed them as-is into our normal image. It looks like something that should be supported properly within the kernel and not done via copy/pasting.
Use the backup function in the LE settings add-on, it exists for a several good reasons:
a) backup up the contents of the /storage partition is always faster than making an image of the entire partition
b) restoring the contents is always faster too
c) no partition size shenanigans to deal with
There is a time/place in the LE ecosystem for cloning tools. Backup is never it.