Posts by chewitt

Quote from heysoundude

So slyguy is pirate. CBC, because it’s not an official app, is pirate. Both are legally available in Canada, SlyGuy’s PlutoTV etc etc, I mean, he just makes it more accessible/easier to integrate…but yaaar, I get it.

Nope, you don't get it. The Slyguy repo and those streaming services add-ons are not pirate. You need to have normal (legal) access to those services to use the add-ons with Kodi. If you're in the wrong region and/or don't have the the required accounts, they don't work. Random user showing up here with IPTV-simple and 4,500+ channels is the pirate.

See https://github.com/LibreELEC/LibreELEC.tv/pull/12013

Quote from heysoundude

What are “pirate” IPTV sources?

Any IPTV subscription service offering a global assortment and thousands of channels. Legitimate sources generally have low 10's of channels limited to a single country or small region. If we see obvious pirate feeds in use, support is refused.

Quote from softwares

Perhaps the switch case should be extended to 2|3|4 instead of 2|3?

That sounds plausible. Keep us posted

I pushed a set of updated Amlogic images to my test share. Notable changes are:

• Kodi 22-RC2
• Linux 7.3.4
• AV1 stateless hardware decode on S4
• VC1 stateless hardware decode on GXBB/GXL/GXM/G12A/G12B/SM1 (S4 needs Amlogic firmware and more work)

Once an LE13 beta ships I plan to revise current DVB support to use a new driver from rozpruwacz and start work on support for SC2 (S905X4) and T7 (A311D2) boards.

The tailscale add-on was largely developed by Claude (driven by me, who is not a software architect) over a long weekend at Kodi DevCon when lots of beer was drunk. I'm still amazed it works at all, so there are likely many opportunities for improvement

balbes150 Привет товарищ

Send new device-trees to the mailing list, then they get added and supported upstream. Where do you publish image sources now?

If you Google on the Shield's remote there's a bazillion posts about disconnects under Windows and Android and there are patches that reconfigure the BT stack to hold the connection; but this negatively impacts on battery lifespan. I didn't find much comment on Linux use, and nothing that I'd consider as a workaround (so far).

Quote from grahamh

Oops! I meant 3588 - Rock 5B+

I ran smoke tests on a Rock5B a coupe of weeks ago and it ran fine (some frame drops when the OSD is active) but I have other things to finish before I circle back and think about creating test images.

Quote from Dr. Seltsam

The wiki article does not describe how to configure IR remote wakeup.

The IR wake code is hardcoded in the BL301 component of the boot firmware. ISTR that CE uses a custom version of BL301 source with some closed-source companion code to support external configuration. At some point I'll get around to investigating and then replicating something similar but a) done with open sources and mainline u-boot, b) upstreamed so everyone can benefit. I have a rather long to-do list at the moment though.

Quote from Da Flex

OK, so why does that "wakeup" file exist, if at all?

Because Google AI is crap and suggested modifying the device-tree to add wakeup-source; and thus the kernel now blindly exposes support for something that the hardware does not support being controlled from the kernel (it is hardcoded in BL301).

I linked the LE wiki article with instructions for creating a custom keymap in post #192. LE does not run the Amlogic vendor kernel that CE/Odroid wikis are written for. If you continue to use the wrong instructions ..

And you cannot change permissions on /sys and /proc folders that are owned/managed by the kernel. That's basic Linux sysadmin knowledge. Again, whatever instructions you are following are not for the mainline kernel.

Quote from grahamh

chewitt Is this portable to RK3288?

No hope whatsoever. RK3288 is about a decade too old in terms of CPU/GPU performance.

Quote from siriusbox

Since the exact same behaviour occurs with two different remotes, two different Bluetooth chipsets and two different LibreELEC builds, I suspect this might be a software compatibility issue rather than a hardware fault.

It's probably a Bluetooth LE (Low Energy) device and thus drops into deep sleep mode to save battery. I see the same with a couple of BT remotes that I have. Investigating how to avoid "press button to wake remote, wait, press again for the action" has been on my rainy-day project list for a couple of years, but it doesn't rain much where I live..

Quote from the_jaguar

btw, does this work on a Pi4 too or does it require a Pi5?

It's untested but IMHO unlikely to work on RPi4 as its GPU has about 50% the grunt of an RPi5 which is already on the marginal end of support, and DV depends on GPU performance.

The IR remote that Hardkernel sells is supported out-of-box on Odroid boards and we use Hardkernel's BL301 sources for the boot firmware so that remote should also support IR wake. Any other remote will need to be configured with the scan codes:

https://wiki.libreelec.tv/configuration/ir-remotes#configuration-advanced

NB: LE does not currently support programming the IR wake codes into boot firmware, but at some point we should probably look at adding that capability into mainline u-boot so the feature is available to all devices.

The only thing that can dynamically change is an add-on. Look at the add-on update history.

Quote from HiassofT

chewitt I guess this patch should better be dropped and intel devs need to fix the issue properly

I don't think this would cause problems. The patch caps the DRM connector at 10-bit output to prevent it ending up in 12-bit which results in bandwidth issues when HBR audio is present. For DV output we are tunnelling in 8-bit RGB and avoid the problem. I don't see DV issues with a Generic build based on current development running on an N150 box.

That patch is a hack though, so a candidate for improvement as userspace vs. kernel colour support evolves.

The only committed changes in our 12.2 branch since 12.2.1 (last November) have been add-ons and (ironically) timezone and root cert updates, but without any significant changes to warrant pushing another formal release out, there hasn't been one, and for the same reason we stopped LE12.2 nightlies a while ago too, so development has focussed on LE13.

We should/could maybe look at publishing root certs and timezone changes as add-ons to prolong the lifespan of the base images for longer without the need for a full image update. That's probably a rainy day project though..