Posts by chewitt

It may help to have 1080p 60/59.94/50/24/23.976 modes whitelisted and adjust refresh start/stop enabled as it will eliminate or greatly reduce the amount of correction Kodi needs to attempt; as the decoder doesn't handle correction too well (same issue as seeking). There is no known list of problem media configs/types so nothing to avoid .. it either works or doesn't.

I'd be interested in a sample of the file for long-term testing with problem media, but currently there isn't anything I can do about fixing the decoder so my advice would be to transcode the file to H264.

frakkin64 the two patches I picked off the list are here: https://github.com/chewitt/connman/commits/invalid-key

An image for RPi4 with two additional patches from the connman list for someone to test. I have low expectations that either patch will resolve anything, but for the sake of a 30-second rebuild: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.1.tar

[Unit]
Description=ngroc service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/path/to/ngrok tcp 22

[Install]
WantedBy=multi-user.target

^ something like that in /storage/.config/system.d/ngrok.service

Then "systemctl enable /storage/.config/system.d/ngrok.service" and "systemctl start ngrok.service" .. it should then be persistent over restarts and even upgrades (as long as ngrok itself continues to run).

Run "getedid create" with the system on/working and the EDID data from the HDMI connection is captured and cached so the HTPC will always see the AVR/TV as being connected. Much easier than scripts.

Over time the software packages we use evolve; normally adding support for new hardware and features, and occasionally doing spring cleaning to drop support for old hardware. The version of mesa we use in LE11 (mesa is responsible for 2D graphics like the Kodi GUI) has done spring cleaning since the version used in LE10 and the GMA950 card appears to be one of the casualties.

Options are:

a) Custom image that uses an older (pre spring-clean) mesa version

b) Disable onboard video (if possible?) and use a newer supported card

c) Stick with LE10

A is not guaranteed to be possible, but also not hard to try if you have some self-building skills. If tempted with B, pick a newer Intel or AMD card, not nVidia (else you are forced to use the Generic legacy version of LE). C is the easy option.

I've dug my own Hub out, and mine is definitely bad joints on the UART connector. If I press the connector from a certain angle (forcing the bad joint to connect) it boots fine. If the cable is just connected it always ends up in the u-boot console. In current state, that means it's great for experimenting with u-boot though.

Based on the total number of issue reports to this forum and our IRC channel I'm calculating this problem is impacting ~0.0009% of the users running LE11 images. That level of "failure" is excellent. Of course we would prefer it to be 0%, but as with most things in life 100% perfect is never realistic and/or would require so much time/effort and testing that some combination of "no fool would ever volunteer to the project" and "sorry, too busy testing to make releases" would apply. At some point you have to call time and cut the release. You are all welcome to roll back to something earlier if that works for you. You are all welcome to go play with Kodi on Android or Windows or .. some other distro too; if you feel we're doing such an intolerable job.

In reference to patches; the "service: Fix hidden service with wrong passphrase" patch is adding support for flagging an invalid-key, not resolving an issue where invalid-key is being flagged which is a subtle but important difference. IMHO the description contains all the right keywords to sound interesting but I don't think this is relevant. No harm in testing it though.

As nobody on staff can reproduce this .. someone needs to start sharing connman and iwd debug logs. They will be verbose and sizeable but are often quite human-readable. The issue is likely in the comms between connman and iwd.

If your network and the internet are good, the low-quality (or in current world situation, over-subscribed) pirate IPTV service is the issue and cache fiddling cannot resolve slow streams. Forcing Kodi to increase cache size just means you wait long for the stream to start and wait longer for the cache to refil and restart playback when the stream stalls. Удачі..

The Telos and Meta boards are based on the same design. I'm not saying that's the same design as your board (no idea). Start with the p200.

It looks like it crashes in the i915 graphics driver. I'm not sure why.. others may comment though.

Someone swapping their drives from NTFS to EXT4 would at least eliminate or confirm the issue is related to NTFS; if the problem goes away it's something in the in-kernel filesystem driver. If it occurs with EXT4 then it's something else.

The Telos/Meta variants are 2GB, the pro is 1GB; otherwise they're based on the same board design (derived from the P200 reference board) and have much the same features.

If all you want/need to do is edit files in the OS, enable SSH access and connect using PuTTY (on Windows) and use nano to edit files. It's a lot less hassle than (re)booting from another OS to make minor changes.

libdsm is a lightweight SMB client that VLC uses for browsing SMB shares. Kodi has an SMB client that it uses for browsing SMB shares. Kodi does not support alternatives; because there's no need for that .. it already has an SMB client. If for some reason that doesn't work you can also use kernel SMB capabilities to mount a remote filesystem to a path on the local host .. but that kind of thing is not really required as Kodi has a perfectly good SMB client.

ngrok would probably have dependencies on networking so systemd would always be the better approach since you can sequence the start to happen after the network is up/online.

You can add a systemd service file in /storage/.config/system.d to execute commands

Unless you share the boot logs there is nothing to take a stab at.