Posts by chewitt

The kernel DRM layer exposes cards and 'connectors' see "tail /sys/class/drm/*/status" and it's possible to delete connectors (and thus prevent them being used) via kernel boot params. For example, appending "video=HDMI-A-1:d" to params in /flash/syslinux.cfg will prevent that connection from being used/visible to userspace. So you can script making /flash read-write and then use sed or awk to rewrite the boot params; then reboot to effect the change.

Portainer isn't listed in the LSIO fleet now https://fleet.linuxserver.io/ hence it's not available in the LSIO add-on repo either. I'm fairly sure it was there in the past, hence there might be posts referring to it in old form threads. You'll need to install it from another source using the SSH console.

Intel CPUs will be supported as long as Intel continues to upstream and maintain support for them: which is likely, although there is always some delay between latest chip and latest kernel having support. If the old DVB-S card still has the correct slot and drivers in the OS it should continue to work the same old way.

The devices clearly connect so it's a likely a protocol issue and one of the challenges with old Windows (WinXP/7/8) these days is changes to crypto. Have a play with the other 'client' options in the local security policy list too (and yes, reboot required, it's Windows).

Control Panel > Administrative Tools > Local Security Policy > Enable - Microsoft Network Client: send unencrypted password to third party SMB servers. When asked for credentials use "servername\username" format.

^ Guessing based on some Google searching. Win8.1 license keys should be eligible for a free Win10 or Win11 upgrade and from a security, usability and compatibility perspective it would be a good move.

The SMB "Client" config in Kodi settings has nothing to do with the Samba "Server" which can be enabled (on/off and the password changed) in the LE settings add-on. The default Samba config can be overriden by renaming samba.conf.sample to samba.conf and editing to include whatever changes you want then reboot to effect the change. If no custom config is present it boots using a default config that supports SMB2 and SMB3 and unless you force different behaviour via registry tweaks Windows clients will connect at SMB v2 and then negotiate up to v3 if the server supports them. The Wireshark trace shows the client device connecting and then trying to negotiate an SMB2 connection which fails with the server issuing a STATUS_NOT_SUPPORTED response. I've no idea why that happens and you proved the server is running and can be browsed from the Linux device.

I'd suggest testing a current LE12 nightly on an SD card as there are some general Samba changes in the newer image (in addition to newer samba server version).

If he's motivated you can point your friend to:

https://wiki.libreelec.tv/development/build-basics

https://wiki.libreelec.tv/development/build-commands/build-commands-le-12.0.x

LibreELEC.tv/scripts/uboot_helper at master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

The uboot_helper file defines the image name and the u-boot defconfig and device-tree file to use for boot. You also need to patch the kernel to include the same device-tree using a diff patch which the build-system applies onto the upstream sources at build time.

NB: In the Android TV box world users sometimes download all the images for a SoC type to see what works (or is least-worst) and you could try that approach too. The challenge with SBC's is that board plumbing tends to be more unique to the board vs Android box devices which are often copy/paste from a refrence design and thus quite likely to work with a wrong but-close-enough device-tree. If the board boots from SD card (might need emmc storage erasing to force that) it's a simple and harmless experiment to do though.

There's no dedicated device-tree file for the board in the upstream kernel and a brief Google doesn't find any obvious mentions of the board being used with other upstream oriented distros like Armbian. I can only find Linux 4.4 BSP sources, which aren't much use to anyone. Those sources do claim the board is compatible with the RK3399 evb (evaluation board) but whether that's true or (more likely) the ASUS developers were just too lazy to create a unique device-tree file is anyone's guess. The evb board is supported upstream but you'd need to build a custom LE board image to test it. The RK3399 SoC is well supported upstream so it's probably not a herculean task to fabricate a dedicated device-tree file; but that effort really needs to be done by someone who has the board to test things, and is motivated to do the work.

TL/DR: no current LE support for this specific RK3399 board. If you can find examples of someone creating a Linux 6.1 or newer device-tree file for the board and have a Tinkering [sic] mindset you can probably self-build an LE image.

Remove all 720p modes and allow Kodi to upscale SD/720p content to 1080p (which is not taxing for hardware). This allows a wider range of refresh rates to see an exact match. You don't need to enable 3:2 pulldown as your TV supports exact modes.

I also forgot to mention the <cache> options in advancedsettings.xml. Unless your network is broken (in which case the solution is to fix your network) cache fiddling is not required and frequently causes issues.

No Pi board can hardware decode VP9 and RPi4 doesn't have quite enough CPU grunt to handle it consistently at 1080p in software so it's best to disable it in inputstream.adaptive settings so YouTube and similar add-ons default to H264 content. This will limit you to 1080p which is the max resolution for the H264 codec on RPi4. If you go above 1080p with H264 the media is software decoded and (again) there's not enough CPU to handle the task so stuttering is expected. NB: RPi5 can handle 1080p VP9 with no problems and a suprising amount of 4K VP and H264 media also plays; not everything is guaranteed but the 250% CPU performance bump adds headroom and more things are in range.

2023-11-02 16:11:19.182 T:7971     info <general>: [WHITELIST] Searching the whitelist for: width: 1280, height: 720, fps: 15.000, 3D: false
2023-11-02 16:11:19.182 T:7971    debug <general>: [WHITELIST] Searching for an exact resolution with an exact refresh rate
2023-11-02 16:11:19.183 T:7971    debug <general>: [WHITELIST] No match for an exact resolution with an exact refresh rate
2023-11-02 16:11:19.183 T:7971    debug <general>: [WHITELIST] Searching for a desktop resolution with an exact refresh rate
2023-11-02 16:11:19.184 T:7971    debug <general>: [WHITELIST] No match for a desktop resolution with an exact refresh rate
2023-11-02 16:11:19.184 T:7971    debug <general>: [WHITELIST] No resolution matched
2023-11-02 16:11:19.184 T:7971     info <general>: Display resolution ADJUST : 1920x1080 @ 29.970032 Hz (34) (weight: 0.000)

You haven't enabled debug and then rebooted before playing things so the front part of the log is missing debug information on what the WHITELIST configuration is, but a number of the YouTube videos and the above show the same thing: media is not finding a correct mode in the whitelist for the type of media being played. Several YouTube plays show 720@30p media and Kodi picking [email protected] which is going to result in corrections, and those are likely the source of the audio stutters. The log above is also weird since 720@15p is a really odd format to have things in. However with correct settings Kodi should be able to play it.

Kodi needs to have adjust-refresh enabled (appears to be) and with 1080p@60/59.94/50/24/23.976 modes selected (30/29.97/25 are omitted) and with "allow rate doubling" enabled. This should result in 29.97fps media being played at 59.94fps, and 15fps media being "doubled" up to play at 60fps (doubling isn't a completely accurate description). The 30/29.97/25 modes are normally omitted to allow interlaced media to be rendered correctly (each interlaced half-frame can be rendered in a full frame).

TL/DR: I believe 1080@30 is not in the current whitelist although the log shows the TV supports this.

If you're going to share a log please share the whole log, else we miss a bunch of stuff that is important. Rinse/repeat with the v12 nightly.

The resize issue is something we're aware of .. enjoy the Pi

The only error I can see in the snippet is the icon.png loading error, and that's effectively harmless. Share a full debug log.

/storage/.kodi exists .. the . is not optional

The first thing I'd check/change or experiment with is the HDMI cable(s) used. ATMOS and other high-bitrate formats are often combined with 4K/HDR video and the combination requires more data to be transmitted on the cable and this means higher bandwidth "certified" cables are needed. HDMI cables also impact the EDID data carried on the HDMI connection which advertises the audio capabilities to the Pi device. As a secondary thing I'd check for AVR firmware updates. AVR devices do ship with bugs that do get fixed in later updates sometimes.

Quote from Billzilla

There's two HDD's, one 6 tb and an 8 tb. They are just average drives, so probably plenty fast enough I'd guess.

There can be a huge performance difference between proper NAS drives in a RAID config where you typically use a larger number of smaller drives to achieve capacity and access performance vs. "JBOD" configs with drives optimised for cost/density: often a single huge platter and not the 3-4 platters of a few years ago. Navigating a filesystem with a large number of inodes (files and sub-directories) results in lots of small file read/write access which is often the opposite of the large file read/write "backups" access profile that cheaper drives are designed for, so it's not uncommon for playback (of a single large file) to be no issue but navigation to be slower.

Are you using library views (Movies/TVShows) or the non-Library (Videos) views to browse media? - If using a library, how many sources are used for each media type? - and are you using default sqlite or MariaDB to host the database?

It's not an obvious configuration and sadly does catch a few people out. I'm not sure what we could really do to improve though.

Quote from itisljar

I'm sorry to intrude, but is this specific to Raspberry or is it for all architectures?

Specific to RPi0/1/2/3 boards. Recent Intel GPU's shouldn't have any problems with H264/HEVC media; AV1 will depend on the chipset.