Posts by chewitt

    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.

    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.

    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.

    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.

    Code
    video=HDMI-A-1:1920x1080M@60D

    Make /flash writeable with mount -o remount,rw /flash then edit /flash/syslinux.cfg in nano and append ^ to kernel boot params (put everything on a single line). Reboot with the HDMI cable connected to HDMI-A-1 and see if forcing the initial DRM connector state to 1080@60 solves the problem?

    If not, create /storage/.kodi/userdata/advancedsettings.xml with the content below and reboot:

    XML
    <?xml version="1.0" encoding="utf-8" ?>
    <advancedsettings version="1.0">
      <general>
        <settinglevel>3</settinglevel>
      </general>
    </advancedsettings>
    Code
    journalctl > /storage/journal.log && journalctl -f >> /storage/journal.log

    SSH in and run ^ after boot. It will dump the initial log to file then tail/append future journal content to the same file. Now go start something playing until it hangs. The logging task will die when the system hangs but the file will remain on-disk after you power cycle and log back in. Then do:

    a) cat /storage/journal.log | paste

    b) cat /storage/.kodi/temp/kodi.old.log | paste

    Share the URL's and if you're lucky there's a trace of something in the system log that correlates to the kodi old log.