Posts by chewitt

  • RK3328 4K HEVC stutter frame drop

    Your can have a fast or cheap solution:

    Fast = Spend $$ on hardware that solves the problem (display that supports 4K@25, or x86_64 board with 10x the CPU resources)

    Cheap = Convert the media (Handbrake is $0, it does batch conversions)

    Choose one option and move forwards. I'm not interested in repeating myself a third time.

  • Help to unbrick a TVbox x96 S905x

    The first thing to do is wire up a UART cable to the board. The pads are in a row of four at the top-right of the board in the upper photo. The square pad is ground, the next two are TX/RX, then +3.3v which doesn't need to be wired. The UART runs at 115200 8/n/1 and allows you to see what happens during boot. Without this you are flying blind and the only response to further posts asking for help and/or saying "that didn't work" is /shrug

    If the eMMC storage is fully erased you can write an AMLGX 'board' image for another GXL/GXM hardware device., e.g VIM1, VIM2, LePotato, etc. to an SD card and see if any of them will boot; first edit the exlinux.conf file to use the p212 device-tree which should work (enough) with any Android box. If the image doesn't boot, try another. The goal is to find an image with u-boot compiled with an acs.bin (which contains RAM spec info) that works with the board. The board has SSV6051P sdio WiFi which is the cheapest of cheap WiFi modules and that normally implies low-spec (low-bin) RAM that's less likely to match against an SBC manufactured with better quality components. Experimenting is free though, and over time I've found quite a few Android boxes that will boot using e.g. LePotato or VIM2 images. If you can boot an image, then you can download the same image to /storage, uncompress it and then 'dd' the image to the /dev/mmcblk1 (eMMC) device and the box should then boot from eMMC again.

    If the board has traces of a wrong u-boot on eMMC (only visible with UART output) then you will need to desolder the eMMC chip to run the u-boot experiments as the bootrom always attempts boot from eMMC first, and the BGA packacing prevents you from doing the normal 'short pins' method (sounds like you figured that out already). The board will then be stuck booting from SD card as resoldering will reinstate the wrong u-boot, but perhaps with the BGA package removed you can see traces and figure out another way to temp short/disable the chip. If you can disable it and boot from SD then you can 'release' the short post boot. The chip can then be detected and becomes something you can erase/overwrite from the console.

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

    If extlinux is /FDTDIR the boot firmware auto-selects the correct device-tree to use whereas /FDT defines a specific device-tree to boot with. I'm not sure how the auto-select in u-boot works for Rockchip (I'd need to go look at current u-boot source) but I trust that Kwiboo knows/knew what he was doing when setting things up like that. To triage the problem you need to attach a UART cable to the board and capture the early boot messages.

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

    LE has some patches for v4l2_request and v4l2_m2m support. We cannot upstream them to Kodi because they depend upon the corresponding set of patches for ffmpeg that are also not upstream. Once the ffmpeg patches get merged and the ABI becomes defined, we'll be able to finalise the Kodi patches and get them merged.

    The issues with Jellyfin files were related to selecting the correct plane supporting 10-bit pixfmt. This is currently done with some simple patches applied to RK images only as Kodi lacks proper logic for plane selection and plane ordering. If you run Kodi under Wayland, the compositor handles this for you, but for GBM use Kodi needs to have its own similar logic.

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

    Quote from diederik

    Dunno if that is in some way relevant for LibreELEC, but it may provide a clue

    I'd expect Wayland to be using zero-copy rendering as this is supported by the DRM layer and Mesa on RK hardware. For zero-copy to work mpv needs to use DRMPRIME pixfmt so buffers contain a pointer to a frame (in DMA) not a decoded frame. I'm not familiar with mpv config options but I'd guess --vo=dmabuf-wayland forces the correct output buffer format (that the compositor expects) for that to work.

    LE is not using mpv or Wayland, but Kodi and ffmpeg support both zero-copy (DRMPRIME) and normal (EGL) output. DRMPRIME is the default in all our ARM SoC images as it's more efficient, which is important for ARM SoC boards.

    NB: I have no playback issues with any of your private test samples on newer RK boards (356X, 3576, 3588).

  • RK3328 4K HEVC stutter frame drop

    There is no magic Kodi configuration that will fix this problem on your hardware. The three solutions are:

    a) Use a monitor or TV that has the required 4K@25 or (doubled) 4K@50 refresh rate so the RK3328 board can play media at native refresh rates without needing CPU conversion to 4K@60 or 1080@60 that a low-spec ARM SoC chip cannot handle.

    b) Use high-spec hardware that can handle the required CPU conversion to 4K@60 or 1080@60.

    c) Convert problem media (offline, using Handbrake) from 4K@25 to something that matches monitor modes, i.e. 4K@30 so the low-spec ARM SoC hardware can play media at native rates (as with the BBB file).

  • RK3328 4K HEVC stutter frame drop

    Comments:

    a) The desktop resolution is 1080@60.

    b) The whitelist has been configured but the whitelist decision-tree (evaluating what mode from the configuration to use) is not visible when media is played and this normally means adjust-refresh and/or the whitelist are not enabled.

    c) The family-movie file is 3840x2160@25 but there is no 4K@25 mode in the whitelist or EDID data. This means Kodi cannot play media at its native rate or a 'double' of the native rate (4K@50) and must adapt the content. This does not give great results, and there is also no mention of a rate change in the log so it might be converting 4K@25 to 1080@60?

    d) The log does not show playback of the BBB file, but this media is 3840x2160@60 and there is a 3840x2160@60 mode available so Kodi will be able to output at the native resolution/refresh.

    e) The "Impossible to convert between the formats" error is unusual (first time that I see it) and I'm not sure where in code that comes from, but the mention of scaling also makes me think it might be trying to scale 4K@25 to 1080@60.

    f) EDID data shows "IIyama" which is a Monitor brand. If this is a monitor? using a TV with a full selection of modes, ensuring that adjust-refresh and whitelist are enabled and set correctly (as per the article I linked before) the results should be better. The EDID data shows 4K@25/50 and [email protected]/24/25/29.97/30 modes are missing; although enabling rate-doubling means the 25/29.97/30 modes can match with 50/59.94/60. The lack of [email protected] mode means HD movies must be CPU scaled to [email protected] and this can impact overall device performance.

    g) If this is the only screen you have, download Handbrake and convert the problem files to 4K@30 and they should play better on a device that has a 4K@30 (and 4K@60) mode. Configure the phone? to use 4K@30 and then future movies don't require you to convert them with Handbrake.

    TL/DR: Monitors make rubbish TV's /shrug

  • Hauppauge WinTV-NOVA-S2 tuner not recognised

    Quote from jcjefferies

    2013:0462

    The last contribution to linux-media from the Hauppague maintainer was adding some 461 variants. The '0462' PID variant doesn't exist in the Linux 6.17.y kernel and I don't see any patches on kernel mailing lists.

    Hauppague might be under the no-longer-true assumption that LE packages downstream driver collections. That turned out to be a pain in the rear to maintain as we were regularly being held back waiting for sources to be kernel bumped, so we dropped them and we now only support upstream drivers. I'll be happy to pick patches that add drivers that are being upstreamed (patches might need a few more iterations but they are visible on lists etc.) but we aren't adding patches with no plan.

  • RK3328 4K HEVC stutter frame drop

    Quote from Tsxop

    error <general>: CDVDVideoCodecDRMPRIME::FilterOpen - avfilter_graph_config: Function not implemented (-38)

    This ^ is harmless and can be ignored.

    Quote from Tsxop

    I've set resolution to 4K in preferences and in inputstream resolution to 4K too

    Forcing the default resolution to 4K won't help the GUI experience, see https://wiki.libreelec.tv/configuration/4k-hdr and follow the recommendations for setup including the whitelist. Correct config on all ARM SoC hardware is DRMPRIME enabled, HW decoding enabled. Then retest with a current LE13 nightly. If there's still an issue, put Kodi in debug mode, reboot and demonstrate the issue and then "pastekodi" to share the log.

  • Combination of VPN gateway and multimedia device imaginable on basis of LibreELEC?

    I spend a lot of time in Hotels with work and have a couple of small devices. It's a 50/50 idea. Networking is the achilles heel:

    • Hotels have rubbish WiFi
    • LE has no interface for handling WiFi captive portals
    • LE has no interface for handling Ethernet tethering
    • ConnMan has no interface for tethering NIC selection
    • Hotels have inadequate bandwidth
    • Kodi doesn't support transcoding to deal with bandwidth
    • Kodi expects 'Library' DBs and media files to be LAN accessible

    ConnMan is intentionally simple; it was built for a phone which has a maximum of one interface per interface type (Wifi, Ethernet, etc.) so while it will work in multi-NIC scenarios it's not particularly elegant sometimes.

    After connecting to hotel WiFi it's often easier to connect to the LE device over Ethernet to bypass whatever captive portal or auth system the hotel has. Or vice-versa; if there is Ethernet in the room, use it as it'll be more stable. LE doesn't handle swapping the tethering NIC well (currently needs to be done over SSH).

    I use Kodi at home but also have a Plex server running on the NAS that contains media as this doesn't require me to run a VPN to connect to the library, and will transcode to a smaller resolution/bitrate on-demand based on the available bandwidth, although it can take a while to iterate down the quality ladder to a point where it works. I'm not wow'd with Plex, and if I hadn't been given a free lifetime pass some years ago (when the Plex 'embedded' fork of LE was a thing) I'd probably go looking for something else.

    Most of the time connecting a laptop to the TV in the room with an HDMI cable and using Plex from macOS (with flirc USB IR for remote work) requires considerably less effort, and ensures the laptop is on a table/desk not on the bed .. better for Zzz quality.

  • Hauppauge WinTV-NOVA-S2 tuner not recognised

    Quote from jcjefferies

    There is no indication anywhere I can see that the tuner is recognised!

    You didn't bother to look in the log then?

    Looks detected to me /shrug

  • Libreelec update from 12.0.2 on RPi4

    Quote from tokul

    I know that I can manually go to 12.2, but I want to see normal update working.

    LE will auto-update within the same release, e.g. 12.0.0 > 12.0.1 > 12.0.2 but not 12.0.x to 12.2.x as 12.2 contains breaking changes for some hardware: not RPi boards, but there's a single rule that applies to all to avoid confusion.

    TL/DR: all is working correctly, do a manual update.