Posts by chewitt

Quote from Smojo

How does LibreELEC solve, that there is actually no 64-Bit Widewine for arm chips

ChromeOS started shipping a 64-bit update image that we could extract 64-bit widevine libs from about two years ago, hence we switched all 64-bit ARM SoC hardware to "aarch64" for LE12 as there was no longer a need to force "arm" userspace.

So we do exactly nothing and inputstream.helper picks the correct version to use; except in your case where some upstream bug has resulted in it installing a 32-bit lib instead of 64-bit, which is not arch compatible and results in errors.

NB: I'm not entirely sure how to reword your too-long and incorrect thread title, but I'll have a go.

It's an IPTV stream (not antenna) hence all the talk of being "on wifi" on the website, but currently it's all wrapped up in a custom app which is only available on the latest-generation TV's. I've seen things written about it being 'open' but then cannot find any technical details and if it's truly open I'd expect it's requirements/methods to become public fact fairly quickly. The one thing I noted from reading around was that it's not possible to record live TV using the app; which would be achievable with Tvheadend providing some kind of intermediate role. No idea though.

To be continued..

nano /path/to/the/file

Use the "nano" editor to open the file ^ and make changes, then "ctrl + o" to save and "ctrl + x" to exit.

I'll put something in the wiki about adapters .. nice to hear it's resolved

Best to ask the add-on author via his GitHub repo, it's not something the core project created.

find /storage/.kodi/addons/tvheadend43 -name lovcombo-all.js

No idea, but that ^ should find it [sic].

The box is running a downstream version of Linux 3.10 from 2013 full of hacky vendor code. There are many improvements to CEC support in Linux since then, but you are stuck with an ancient kernel because the vendor made zero effort to upstream support for their products. The codebase is basically untouched since release.

The same old kernel and surrounding userspace are probably the reason for poor WireGuard support too.

suppenkasper see https://wiki.libreelec.tv/configuration/…reguard-routing

Quote from PeteAklNZ

Any steer on a resolution would be much appreciated.

It's a bug and the fix is merged upstream: https://github.com/tvheadend/tvheadend/pull/1786/files

The fix is included with the Tvheadend add-on in our LE13 repo, but the LE12 add-on is still an older version. You can manually edit the lovcombo-all.js file to effect the fix until the add-on is bumped.

CvH Is there a reason why we've not bumped LE12?

echo "set locale" > /storage/.nanorc

Run that command ^ then logout and back in and see if anything changed? .. NB: Suggested by ChatGPT so no idea if it works

Plan B .. CvH  mglae any input [sic] ?

The ultimate fix would be Kodi evolving proper 'hotplug' support so that audio/video properties are dynamic rather instead of being fixed at startup, but it's one of those problems which ends up touching more bits of the codebase than you'd initially think, which is probably why nobody has willingly volunteered to tackle it yet. Until then the EDID workaround is good.

Quote from deleonkikko

Any suggestions?

Post in balbes150 support thread as he creates those images, not us.

First, also test a current LE13 image in case it's something already resolved?

If not resolved, have a look in https://test.libreelec.tv/12.0/Generic/Generic/ and starting with the oldest development image (at the top of the file listing) to see if that has the same issue. If no problem we need to "bisect" (a halving process) the list of images to find out when the breaking change has occured; we can then cross-reference that to changes in GitHub. If the same issue is present and there are success reports from other users, I'm not sure we will figure it out easily as LE11 images were deleted when development switched to LE13.

HDMI uses active negotiation/handshaking on both ends when things are connected/unplugged or turned on/off. Kodi will respond to video capability changes, but audio capabilities are only detected once at startup. You cannot tell LE/Kodi to leave video on (as that's not how things work) but you can capture the EDID data that describes the connected HDMI properties and configure/force the Linux DRM layer to always see the AVR as being present, which achieves the same thing. Run "getedid create" from the console and then reboot, then run some tests. See https://wiki.libreelec.tv/configuration/edid

Google (AI) tells me that Freely's IPTV services are not DRM encryptied, but I'm not able to find any information online (from a brief search) about how you would configure something. Everything talks about "using your Freely equipped TV" and that appears to be based on an app (OpApp) embedded in the TV's OS rather than accessing from something else.

noggin Can you share any light on what might be possible?

Quote from schneiderlein

Maybe its something because of newer libdvdcss versions coming with LE12 that breaks compatibility

I think that's unlikely, but it's easy to test with older LE official releases and/or nightly LE12 images with older versions installed.

IMHO it's more likely that the old drive needs lens cleaning or replacement. I have a couple of really old (and really slow) SCSI cdrom drives that were clearly built to last that still work great despite being around on the planet longer than my teenage daughter, while anything newer (and faster) with an IDE/SATA connector seems to last a couple of years before dying for no explicable reason.

Quote from srazor

The only reason is that there is no acestream version for arm64 LE12/13 out of the box

Awesome! We are always delighted to hear piracy apps don't work. Long may that continue

I'm still using the original 'Amazon essentials' micro-HDMI to full size HDMI cable the RPi devs shipped out with the original RPi4 pre-production samples and it's never given problems. I prefer that to using adapters, and we do see occsasional issues from users with adapters being reported.

No harm in testing a different HDMI source too, but there's nothing exotic about the RPi board's HDMI output, so I wouldn't expect that to show any change.