Posts by chewitt

  • SVT Play livestream spontaneously quits after 1 second if played on LibreElec

    Quote from nosen

    One, I want to use the stable branch so that I don't have to deal with stability problems, and two, I think it's useful to keep debugging this so we may identify the bug, and stop it from popping up again later.

    I've been running self-built LE13 nightlies for the last ~2 years and the only time they have been unstable is when I've been doing intentional experimenting of my own, but even that's been low drama. The nature of the LE 12.2 release means it's prob. received considerably less staff runtime testing than LE13 nightlies; but hey, users do obsess over the 'stable' label.

    As you're the single LE user reporting the problem and there appears to be a valid workaround I have low interest in chasing the problem on LE12.2 .. esp. when you're already trying to pass the buck and avoid doing the test I've already suggested that might narrow the scope of the problem. The differences between LE12.0 and LE12.2 are too large to do anything but guess, and even if something was obvious the solution is unlikely to go into an LE12.2 image (as there isn't expected to be another release) so the fix would be in LE13 (which doesn't appear to need one).

    Quote

    I want to be crystal clear: the bug only manifests on a small subsection of content, namely live tv i.e. the same thing you'd see on the regular terrestial broadcast

    That ^ wasn't fully obvious in the original report (and perhaps not to the GitHub thread either). Kodi is essentially a big fancy wrapper around ffmpeg's capabilites for playback, and since the kernel and ffmpeg versions/patches in LE12.2 and LE13 are the same, I'd still be thinking about config and behaviour of the add-on more than the OS.

  • SVT Play livestream spontaneously quits after 1 second if played on LibreElec

    LE12.2 is a fork of the LE13 codebase from a couple of months back retrofitted with K21 not K22, and notably with the same ffmpeg version used in both. So if you want to play 'spot the difference' there's more in-common between the LE12.2 and LE13 than there is between LE12.0 and LE12.2 (and that difference is too large to spot anything). Combine that with the add-on working for multiple users with non geoblocked content on both releases and my suspicions are towards add-on config or something environmental not an issue with the base OS; and hence the suggestion to test that theory.

  • Syncing profiles with server

    Nothing changed. Kodi allows you to create different profiles and to use a remote DB to store library and some (but not all) config data. However there is no concept of roaming profiles or a Kodi-internal way to keep data synchronised over multiple devices. You always need some form of external-to-Kodi sync, and being 'external' this inherently runs into data consistency issues.

  • SVT Play livestream spontaneously quits after 1 second if played on LibreElec

    I'm not an expert in reading streaming service logs (and different services will behave differently) but it looks like audio and video are separate streams, and everything goes through a normal looking process of obtaining stream manifestsa and then selecting audio and video streams. The audio stream looks to be selected, but then the video stream switches from SD (448x252@50) to HD (1080p@50) and then the stream stalls.

    There are quite a lot of streaming add-ons installed so I would be interested to see logs from a current LE13 nightly that has only the SVT play and inputstream.adaptive add-ons installed. I'm not expecting anything to be different, but it will remove some noise from the log. I don't see any 'errors' that would e.g. indicate Python issues or something that traces back to the underlying OS. IMHO if there's a difference between the add-on under LE and the add-on the author tested on Ubuntu it's more likely to be add-on or i.a configuration and not the OS environment.

    NB: The stream is H264 and RPi5 does not have H264 hardware decode or hardware deinterlacing so the v4l2_m2m errors in the log that Da Flex has seized upon are nothing more than ffmpeg correctly failing to find hardware decode and deinterlace /dev/video nodes that don't exist and failing back to use software capabilities. All normal and expected on an RPi5 device.

  • Changed behaviour of screensaver black between -11 and 12

    I'm using 'black' as the screensaver with a variety of ARM SoC boards since forever and nothing has changed. I'm admittedly using LE13 images for a long time now but when I was using LE12 in the past (and LE12.2 is based on the same Kodi codebase/version) it worked fine. The description of "First couple of seconds it's dark grey, then pitch black" sounds more like the TV having an issue.

  • DHCP with Manual DNS

    I'd argue the bug is not strictly adhering to the logic of using DHCP .. OR .. manual configuration, i.e. If you switch from DHCP to manual I would expect that the correct action is forcing the user to (re)define everything from scratch. That's probably an issue with our implementation of a ConnMan agent, and something to fix.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Code
    Machine model: Rockchip RK3566 BOX DEMO V10 ANDROID Board

    I'm not sure if this ^ is the same as the evalation (evb) boards present in u-boot/kernel, but if I was building an image to experiment from that would be my starting point. That said, device-tree changes/improvements to RK boards in the kernel seem to be made on a very individual basis (no bulk enablements etc.) so you may also find the evb files need some fixups; they are inherently often the first board to be added for each SoC type, and then development focus quickly switches to commercially available boards, so the evb boards fall behind current driver capabilities over time.