Code
nano /path/to/the/fileUse the "nano" editor to open the file ^ and make changes, then "ctrl + o" to save and "ctrl + x" to exit.
Posts by chewitt
-
-
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.
-
Code
find /storage/.kodi/addons/tvheadend43 -name lovcombo-all.jsNo 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. -
-
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?
-
-
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.
-
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?
-
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.
-
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.
-
It's possible and has been done. It's not something we formally support though, so there's (intentionally) no written guides on the process. Note that LE supports Docker (via an add-on) so if the goal is to run a bunch of other apps on the same hardware, perhaps investigate using containerised apps rather than using Proxmox.
-
There is no details how to connect video on a specific HDMI
On LE, Kodi does not run under a desktop/windowing environment so display selection is not possible. Instead Kodi will output on the display connector that probed first, and because hardware probe order cannot normally be guaranteed it is not possible to pre-determine which connector will be used.
On a general purpose Linux distro with a desktop/windowing environment you can move the Kodi app window to a specific display and the OS will (or should) remember this, and Kodi will allow you to select a specific display for full-screen output.
In both cases you should be able to select a persistent audio output device in Kodi settings.
