Posts by chewitt

  • add-on dependent vlan

    Not possible. The traffic for an add-on is not 'contained' within Kodi, and Kodi itself does not run 'bound' to a specific interface on the host. So traffic is just traffic and the OS routes it off-host based on the default interface (default route) and static IP routes that send traffic for a specific destination through a specific interface. IP routing rules can achieve what you want to do, but the ruleset will be a non-trivial challenge to create and maintain over time.

  • which LibreElec for mxq pro quick play?

    Have a read: https://wiki.libreelec.tv/hardware/amlogic - the AMLGX "box" image and one of the GXBB (S905) device-trees should be able to boot the board - You'll need to experiment to find out which one works best (or is least-worst) but I'd start with the P201 or P200 dtb files as those are based on the Amlogic reference design which Android boxes are typically derived from. Realtek WiFi and BT might not work, but Ethernet is more important. Please also read LE11 release notes to clearly understand the current state of upstream kernel support for Amlogic hardware.

  • PVR Setup Quick Start Idea

    The Makefile bundles the tables for its own .deb/.rpm packaging which the LE build-system ignores since we're picking the binary blob and some .so bits needed and ignoring everything else. This patch is applied at build-time: https://github.com/LibreELEC/Libr…scan-path.patch and we ship the upstream tables (as stated before).

    Making the inclusion of scan tables and the path to expect them under build-time --configurable would be a nice-to-have change so LE can drop the patch. I have a large to-do list, but I'll add that somewhere.

  • Sata Controller error

    If you clone our repo, make changes, then attempt to push changes to GitHub; You are trying to push your changes to our repo and this fails because you do not have commit rights on our repo. You need to fork our repo to your own GitHub account, make changes in a topic branch in your forked repo, and then send the pull request from your repo to ours.

    Have a read: https://wiki.libreelec.tv/development/git-tutorial

    NB: We expect you to build and prove the changes are correct before sending them. WSL build tips are here: https://wiki.libreelec.tv/development/building-windows-wsl

  • Update is missing or?

    On a conventional Linux distro an upgrade involves changes to thousands of individual files and downgrades if something doesn't work out can be challenging. LE packages the core distro into two files (KERNEL and SYSTEM) so an update from 11.0.1 to 11.0.3 is simple and in the event of a problem an "update" back to 11.0.1 is also simple.

    So I think you should be not scared of updates and answer the question yourself :)

  • PVR Setup Quick Start Idea

    LE bundles the upstream dtv-scan-tables, see: https://github.com/LibreELEC/Libr…package.mk#L132 and https://github.com/LibreELEC/Libr…s/package.mk#L8

    Motivation for the change is here: https://github.com/LibreELEC/LibreELEC.tv/pull/8311

    I'd be keen to encourage Tvheadend and other PVR back-ends to adopt the upstream scan-table repo too. If there's an effort from multiple projects to use and improve the upstream tables we all collectively benefit, and sending a patch to a mailing list isn't really any harder for users than sending a pull-request; it's just a new skill to learn (one that's easily coached with a good wiki article) and requires a little discipline from project maintainers to politely refuse/redirect user contributions.

  • PVR Setup Quick Start Idea

    Quote from emveepee

    Even as TVHeadend under chewitt's new participation will become even more of a focus for LE, I am hoping that there would be an option to use NextPVR if an appliance mode is considered and I would really like to be involved.

    I have an interest in both projects, but I have no interest in forcing either project on the other. If LE decides to do or allow more with PVR then it will always be a team decision; but one that's ultimately driven by people showing up on GitHub with some quality pull requests to add the required changes. We (maintainers) are risk averse and will want to have a clear vision for how things will look and work - at both user-storyboard and code levels. Please also understand that LE has history with new-ish people showing up and trying to push poorly considered changes into our codebase (our indigestion on the experience and their intollerance resulted in CE) and there's a current and live example unfolding in Team Kodi at the moment with a well intended feature impacting a release cycle and needing a massive group effort to fixup code that (with the benefit of hindsight) shouldn't have been merged so quickly.

    DeltaMikeCharlie I'll ping Jason offline to see if he has any plans for the add-on, but if it's unmaintained for two years we prob. already have an answer. You don't have to reuse it, but if it's already a reasonable match for where you wanted to go with things adapting prior art is often faster than writing from scratch. Your call entirely.

  • mmu page fault on Odroid C2

    The "lima" driver is responsible for 2D graphics (the Kodi GUI) rendering. Do you have a visualiser running while music is playing?

    If yes, disable it or change it and see if that makes any difference?

    You can also update to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar which has newer kernel (so newer lima driver) + newer mesa + newer Kodi .. will be LE12 once Kodi moves to RC and we can release a formal beta. Newer is not always better, but newer is different, so we can see if it influences the outcome.

    NB: I also have no idea how to debug this :)

  • Update is missing or?

    LE 11.0.4 will be published shortly, but we will not enable auto-update until after Christmas at least, as we don't want to generate extra support traffic over the holiday period. You will be able to manually update once it's on the servers.

  • PVR Setup Quick Start Idea

    Some morning brain farts:

    It would be simple to do a custom LE image aimed at e.g. Tvheadend with more built-in/pre-configured. However the main challenge with DVB is that half the cards users show up with require a non-standard kernel hacked to run with a not-upstream driver so the more appliance-like you make a DVB image, the more limited the audience of users it might work-for becomes. The secondary issue is the inherent diversity of a global audience. LE active-install stats show we have more German (#1), Czech (#3), Spanish (#4) and French (#5) installs than English-speaking US/UK/CA/AU countries combined (#2/#6/#8/#9) so one design danger is assuming the audience and config requirements we see from (English-speaking) forums looks like the one we're most familiar with.

    The add-on from edit4ever might be a good base to work from: https://github.com/edit4ever/script.module.tvh2kodi - the last update was a couple of years ago and Jason hasn't been active around here for a while so it probably needs some work. With my LE hat on: It would be great to have it combined with a setup wizard in our repo to make it more accessible. With my Tvheadend hat on: I don't believe the add-on depends on LE so updating and publishing to the Kodi add-on repo or perhaps to an independent repo that Tvheadend manages would increase the potential audience; albeit at the expense of integration with the LE settings add-on. NB: Tight integration creates the best user experience but typically increases maintenance and if you sense any hesitancy among project maintainers towards integrations; it's because we have an underlying desire to keep things as simple and low-maintenance and sustainable as possible. With that in mind, I suspect a series of good HOWTO guides for the main PVR back-ends in the LE wiki would be a good start for our users.