Posts by chewitt

    Kodi was making requests from high number ports vs. just straight from secure http on 443

    That's normal and correct behaviour. There are muliple processes inside Kodi that might need to communicate to a remote service on 443 at the same time. If only outbound 443 could be used they would all have to queue up and wait for their turn to use the port, and you'd need some clever scheduling code to manage all the requests. If each process communicate outbound on a random port they can all talk at the same time and stuff gets done a lot faster. It's how all modern TCP/IP apps work.

    I did a little digging on our side this morning. I can see requests in the addons webserver access log from an RPi3 running an old Milhouse image. This is hammering the server with multiple requests/second, which is not normal behaviour and suggests some kind of issue somewhere, but according to the webserver logs we are responding (HTTP 206 status responses). I see no requests from any other device (from the same static IP) and no other HTTP status response codes, e.g. 404's or such, only 206's.

    From what I can see on our end, the issue isn't on our end.

    in "settings / display / framerate" the framerate is set to 50fps. When i Play a Video with 24fps after pausing the Video i have micro stuttering for a while. I don't have that Problem when the Video has 25fps. Is there a Solution for that Problem?

    Don't force 24Hz content to play at 50Hz?

    Use the mode whitelist to enable 1080 @ 60/50.94/50/24/23.976, allow double rates, and enable adjust-refresh.

    That makes no sense to me because the default u-boot behaviour (without the patch) is to search for dtb files in /amlogic/ and that's where the files exist (image below shows the layout on the SD card). In older LE images the files are placed in the root folder, hence needing the patch.

    I'm wondering if the paths are being appended. If you create /amlogic/amlogic/meson-g12b-odroid-n2-plus.dtb on the default image (without the patch) does the board boot?

    Kodi in LE has been compiled with an internal SMB client (libsmbclient) which is independent and separately configurable to the 'smbclient' binary derived from Samba which is also embedded in the OS. Both follow the default 'Samba' behaviour of SMBv2 min and SMBv3 max, meaning clients connect at SMBv2 and (re)negotiate to SMBv3 if the server supports it, unless manually forced to use min/max SMBv3 or min/max SMBv1 only. If users set min SMBv1 and max SMBv3 the client still tries to connect at SMBv2, and this has been the Samba default for at least a decade now (as SMBv1 has long been considered wildly insecure).

    The Kodi smb client can be configured with different read/write cache sizes. LE uses the Kodi defaults which can be overriden (with mostly negative effects). In older Kodi versions this is done from advancedsettings.xml. From Kodi 21 (LE12) the default SMB read chunk size was changed and can now be configured from the Kodi GUI which helps with some scenarios. Are all the Kodi clients running the same Kodi version?

    I have zero knowledge on Jellyfin clients, but they may work in a similar fashion to Kodi with different caching and protocol support in different OS and app versions. If you want to test for SMBv1 or SMBv2/v3 use, you should be able to disable SMBv1 support on the Lubuntu server (and you should do this anyway) and if things break, it was using SMBv1 (which is slower) to connect.

    The only other thing which normally impacts SMB transfer speeds is the filesystem driver on the server; the main problem being that users have NTFS drives which are poorly supported in the host OS. These days LE uses in-kernel NTFSv3 drivers. In the past we used NTFS-3G which are userspace (and thus much slower) drivers - and this is still the default in most distros. However that's a server side restriction so it would limit transfter speeds to all SMB clients, so that's unlikely to be the reason.

    /shrug

    Offline DV media is generally encoded with a fall-back to HDR10 so devices like RPi5 which do not support DV itself can still play HDR with correct colours. Online streaming media from DV enabled services (and rips of those services) are generally encoded without the HDR fall-back so will show wrong colours.

    I can get to skins now - that must have been about getting all my regional stuff set correctly

    NB: It has nothing to do with regional settings in Kodi, but might have something to do with geo-region as Team Kodi serves content through a network of third-party mirror servers. LE does too, and although our list of mirrors is smaller and less sophisticated than Kodi's, most of our mirrors are also in their list so an issue with a particular mirror (nearest to you is the logic used) may impact LE and Kodi at the same time. Looking in the debug log should show which is being used.