Do you have any advice or experineces whether a bigger passive heatsink (e.g. using the Flirc case) or other optimazations could help me to increase the max. playable bitrate?
Overclock?
Posts by chewitt
-
-
In "textmode" boot a large number of services chained from systemd "user.target" aren't ever started hence audio and other things aren't preconfigured properly for Kodi use. It's interesting to note a possible correlation with Kodi being started, but the assumption that "the hdmi audio device driver falsely grabs the sd-card interface" is creative thinking, but not possible in code.
Have you previously reimaged the box with one of the custom legacy-kernel images? or is/was it still running a factory image? If the former, does the problem exhibit if you restore the box to factory spec first?
-
So, box image on USB---how to edit the uEnv.ini file?
Use Notepad++ on Windows (as unix line-endings are important). Use anything you like on macOS/Linux.
-
If you enable "show hidden files and directories" in Kodi Settings > Media you can use the Kodi filemanager to navigate to /storage and delete the folder.
-
This change was made in LE12: https://github.com/LibreELEC/LibreELEC.tv/pull/8161 and backported to LE11 in https://github.com/LibreELEC/LibreELEC.tv/pull/8180 before LE 11.0.4 was tagged/shipped.
According to the patch/change, using "Shutdown()" as the mapped button command should restore the previous behaviour.
-
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.
-
Perhaps you should steal another version of the file that plays better then?
-
I would remove /storage/.cache and reboot. Fixed?
-
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.
-
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.
-
It's the 23rd December and people are starting to focus on family things so it could be "in the next 24h" .. or it could be "sometime in the next week" ..
-
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
-
Does it make any difference to perform the pairing/truest using bluetoothctl over SSH?
-
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
-
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.
-
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.
-
There are many generations of "MXQ" devices from hundreds of manufacturers. What SoC/Chip is inside the box?
-
And people wonder why we loathe Realtek vendor drivers so much
