Posts by noggin

    The Kodi setting for Limited doesn't do what you think it does I'm afraid. It's been confusing for years.

    The Kodi tick box for Limited Range option is only useful when your OS is using Full range output (and would map black to 0 and white to 255) but you want to force Limited Range output (with black at 16 and white at 235) because you're feeding a display that won't accept Full range output (or you want to preserve <16 and >235 content and/or avoid the banding that rescaling can cause). This was a useful thing with some Intel GPUs a long time ago...

    HDMI InfoFrames these days mean this is less useful than it might seem (as InfoFrames are now routinely used to flag Full or Limited range from source to display). If your OS is already set-up for Limited output then you get grey blacks and dim whites if you also tick the Limited option within Kodi, as you will if your TV is in Full range mode or your OS is in full range mode and TV automatically detects this nd you select Limited in Kodi.

    For a Raspberry Pi, in my experience with Sony and LG TVs, you should leave the Kodi settings on default and your TV Full/Limited range settings on Automatic if you can (so InfoFrames are followed correctlu) If not I'd use Limited (as my TV HDMI setting) as my starting point - as that's the near-universal standard for HDMI video devices.

    I've never had to alter my Kodi settings or TV settings on a Pi 3/4/5 running LibreElec to get correct black and white levels. Most HDMI systems default to 'Limited' or 'Video/Broadcast' levels (16-235/64-940) as that is what broadcast video production and distribution uses (other than Dolby Vision ICtCp stuff). If you remap Video/Limited to Full you can clip <16 Blacker-than-Black (not usually an issue - though it makes PLUGE tricky to use) and >235 Whiter-than-white (more of an issue as 100-109% are valid video levels - particularly in broadcast TV use)

    From your posts above

    TV: Limited
    Kodi: Full (which doesn't actually mean the Pi 5 is using Full range - it just means Kodi isn't compensating for a Full range output to a Limited display...)
    Gui looks the most natural... deepest blue colors from Estuary. HDR content is dark, normal content is normal.

    If the Pi5 is correctly configured for Limited output automatically at an OS level (which happens pretty much all the time on a modern HDMI-connected display) - you shouldn't need to select Limited in Kodi's settings.

    Is what I would expect to be normal. When you say HDR is dark are you objectively comparing it with the same UHD HDR content via a different player route (i.e. comparing a UHD HDR BD player output vs Kod playing a UHD BD rip of the same disc on the same display) or just making a subjective comment (or worse comparing with an HD SDR version of the same content).

    It's normal for HDR versions of movies to appear darker in PQ (i.e. HDR10) HDR than the same movie release in HD SDR (say comparing a UHD HDR BD with an HD SDR BD) because HDR PQ10 is based on SDR content brightness being at 100nits max (with HDR highlights etc. going >100 nits), whereas most people watch SDR content at display settings brighter than this (so the SDR content often hits 200 nits or more), and thus when PQ content keeps the SDR range of an HDR signal at 100nits 'it looks dark' is often the comment you hear (as people are watching SDR content pushed into the HDR range of their displays - as 100 nits is quite dark for normal viewing conditions).

    I guess I'm asking whether you are saying for certain that HDR content is definitely incorrectly replayed - or you just feel it's too dark?


    ***EDIT - It may be best to leave your TV on Automatic rather than fixing it at Full or Limited - as regular SDR content is almost always 16-235/64-940 video/limited levels - as is HLG HDR (as used by services like BBC iPlayer). However PQ/ST.2084/HDR10 stuff may be using 1-1023/1-254 full range instead and flagging accordingly using HDMI Infoframes ***

    Well I had run the fsck to fix the errors so looks like they have re-occurred. I was also testing the 2-part film recording - set one up in the pi web gui choosing the first part, no rec icon in the second part but the scheduled recording showed the correct start and end times for the 2 parts together. But only the first part recorded. Possible error as before.

    I was going to ask what would cause the memory usage to increase as the recording progresses, wondering if it might be a memory leak - but perhaps it is caused by this file buffers issue you mention because of the faulty flash drive. This was a brand new flash drive when I installed it.

    I might replace the usb stick with an external usb-caddied hard drive rather than another solid state. I have a few old HDD's lying around but they are not the AV type, just standard internal HDD. This pi box is only used to record occasionally, but I would still like to get to the bottom of the issue.

    I have set another 2 part recording on my freesat box in the same way to see if that completes both halves. This records fine and the only issues I have with that box is it sometimes completely freezes on playback of files, usually after a skip forward or backwards (through adverts),


    I'd suggest starting with a new, clean, uSD card (uSD cards do fail) and a stock LibreElec install, and ensure you enable the Freeview UK EPG module so you get proper EPG details for the Freeview HD channes on the PSB3/BBCB mux. The Freeview HD EPG may also help with split recordings (or Series Recording rather than basic recording might). I think I usually just make sure I have set recordings for both parts.

    Personally I don't use anything smaller than 32GB these days - and usually use Samsung EVOs.

    Also - just checking you are using a Raspberry Pi-branded PSU or one you absolutely know is reliable for use with a Pi (the Pis take quite a lot of current and are quite particular about voltage and voltage drops across thin cables). It may not be relevant - but I've seen so many Pis do weird things with dodgy powers supplies and dying uSD cards it's something I always check.

    I've never used an AV-labelled drive for TV Headend recording purposes (they are really designed to be quieter as they sit under TVs in PVRs) and any reasonably decent HDD should be fine. I'd recommend externally powered 3.5" drives over bus-powered 2.5" drives though - as PSU issue can be a pain to sort out. Also - some of the latest large capacity external HDDs go to sleep automatically which can cause problems with TV Headend. (I had an issue recently with TV Headend running on an x86 box with OpenMediaVault caused by that)

    TV streams are very low bandwidth so even USB 2.0 connectivity is usually more than adequate for external HDDs - but USB 3.0 makes managing recordings a lot nicer (HD Video is usually <20Mbs - often <10Mbs after all)

    I'd also avoid using web playback as a way of checking recordings - it relies too much on browser playback support. I'd always check by playing the files in VLC using NFS, CIFS/SMB/SAMBA or SFTP to access the recordings on the Pi.

    Freeview HD in the UK uses Huffman encoding for the EPG information (which will display as garbage as above if not correctly decoded). TV Headend has support for this but you have to enable the Freeview UK EPG module in TV Headend for Freeview HD EPG data to be decoded correctly. Freeview SD uses standard EIT EPG standards and works fine without the Freeview UK EPG enabled (confusingly).

    Two reasons for files splitting I can think of :

    1. Reception errors (if you get too many the recording will stop, but I think it will then re-start as if it's missed the beginning?)

    2. Some broadcasters (C5 in the UK in particular) interrupt movies to broadcast a news bulletin - meaning you'll get two recordings not one. If you access the recordings folder outside of TV Headend (i.e. add it as a VIDEOS->FILES location in Kodi) you can play both parts - but TV Headend's UI and PVR Add-on may only show you one.

    -1 on the end of the filename is used to preserve both parts.

    Two other things I'd mention :

    1. For 2160p50 4:2:2 you need an 18Gbs HDMI 2.0-compatible cable - I ensure mine have the HDMI Premium Certified hologram (they aren't expensive). Cables that work with 2160p60 4:2:0 (which is HDMI 1.4 bandwidth) often fall over at 2160p60 4:2:2.

    2. Argon cases with HDMI extenders (little PCBs internally that have MicroHDMI plugs and Micro or Full-size HDMI sockets) to bring the HDMI ports out to the rear of the case are notoriously bad quality - they don't work reliably with 18Gbs HDMI 2.0 signals.

    Sounds like your HiSense only accepts 4:2:0 connections for 2160p50 and above - and not 4:2:2, but your LG accepts 4:2:2 at 2160p50 and above.

    The Pi 4 and Pi 5 don't output 2160p50 and above in 4:2:0 (the Pi doesn't support 4:2:0) so that explains no 2160p60 on your HiSense from the Pi, but the LG being OK with 4:2:2 from the Pi 4/5 at 2160p60.

    WRT to your Denon AVR - there are known issues between Pi5 and Pi5 and some Denon AVRs.

    Da Flex sorry, but Zygmunt is correct here. With an underspecced cable you'll get signal drop outs (down to no signal at all) but you should see 4kp60 listed in settings.

    Missing modes is usually caused by software/EDID issues, i.e. the AVR or TV isn't advertising the correct modes or the RPi4 hasn't been configured to 4kp60 in config.txt and thus won't use the mode, even if the TV/AVR advertises that capability.

    so long,

    Hias


    Yes - and if the TV (or TV input used) only supports 4K60 using 4:2:0 (*) then that will also limit the connections to 2160p30 and below - as the Pi 4B doesn't support 4:2:0 output (and neither does the Pi 5?) because of the requirement for chroma subsampling in two directions (not just one)

    (*) Some TVs - like my two previous Sonys - only support 'Enhanced HDMI' (i.e. 18Gbps modes like 4:2:2 12-bit 4K60) that is needed for 4K60 output from a Pi 4B on two of their HDMI ports (HDMI 2 and 3 on ours), with the other HDMI ports only accepting 4:2:0 at 2160p60 (HDMI 1 and 4). The Pi 4B was limited to 2160p30 on those two limited HDMI ports ISTR (as it was for ports HDMI 2 and 3 if the TV didn't have Enhanced HDMI enabled in settings) as you had to use a <18Gbs mode. Similarly our previous Denon AVR also had to have 'HDMI Enhanced' enabled in its settings to allow 4K60 4:2:2 (and 12-bit) to be accepted - and the front panel HDMI input didn't support it.

    If the TV or TV input is flagging 4:2:0-only via EDID for 4k60 (aka 2160p60) modes then that won't be offered as a resolution by LibreElec as it will know that the Pi4B doesn't support 4:2:0?

    I put it at the last line in config.txt. I tried :

    # hdmi_enable_4kp60=1, #hdmi_enable_4kp60=1 and hdmi_enable_4kp60=1

    Nothing. No 60Hz available. What I am doing wrong?

    Why 60 Hz is not available in the LibreELEC software? I installed 11.0.6

    # before a statement = ignore what follows for the rest of the line. (It's how to put comments in the file, or quickly disable something during testing without deleting it)

    4k60 requires a higher quality cable as the video is carried at a higher speed and thus requires cables capable of carrying the higher bandwidth signal (Don't spend silly money - just buy one that is Premium Certified). 4K30 and below can be carried on older low-bandwidth cables.


    Also - if you have an Argon One case - that can cause all sorts of problem with 4K60 as the HDMI extenders aren't HDMI 2.0 friendly in many cases.

    WVC-1 is probably just a reflection that VC-1 is a Microsoft-originated codec, now ratified by SMPTE (where it got VC-1 naming) and it has Windows/WMV heritage.

    All codecs have a FourCC four-character code - VC-1's is WVC1.

    fourcc: WVC1


    That codec info you provided confirmed it's not an interlaced issue as the video in that file is progressive.

    Hello ,

    yes the newer LibreElec is mostly very stable for the RK3328 Rock64 , however it still would struggle with the VC-1 content, slowing down and eventually reboot. dont know why, as it supposed to have to hardware decoding for such content. maybe the Bluray rips via makemkv is using a codec that is not so well supported?

    now with the rp3 b+, the playback is smooth *with hardware keys for vc1, but again, have to disable wifi everytime manually if i load another OS, which is cumbersome.

    hope to find another SBC that could work well with LibreElec sometime later.

    MakeMKV rips Blu-rays and DVDs in their native codec - so a VC-1 Blu-ray is ripped in VC-1, an h.264 Blu-ray is ripped in h.264, an MPEG2 DVD or Blu-ray is ripped in MPEG2. MakeMKV doesn't change the codec or use its own - it just rips and re-wraps from VOB (DVD) or m2ts (Blu-ray) to mkv containers, also allowing you to remove certain streams (such as audio tracks or subtitles you don't want).

    Some platforms cope differently with interlaced and progressive VC-1. Interlaced VC-1 is used on 1080i25/1080i29.97 TV show releases, progressive VC-1 in 1080p23.976/24 format is used for most movies and some TV shows. Often you find interlaced VC-1 is more of a problem than progressive. MediaInfo (a free solution) will tell you all you need to know about your files (run it on a PC, Mac or Linux platform)

    Don't understand your comment about having to disable WiFi as you change OS. (I assume you mean as you change MicroSD card with different OSs on them in the Pi?)

    I would run the Kodi desktop/GUI at 1080@60 not 4K@30. Use the mode whitelist to permit switching to 4K for media playback when needed but otherwise allow the TV to scale the 1080p skin and 1080p GUI to the panel 4K native resolution using it's native scaling capabilities that do a better job than Kodi and have no load impact on the HTPC device.

    NB: The only hardware that doesn't struggle with 4K desktop output is high(er) end Intel CPUs. All ARM boards run the GUI best at 1080p.

    Yes - or if you're in Europe and watch European DVDs, Live/Recorded TV, or European VoD services (like BBC iPlayer etc.) which are all 25/50fps and have frame rate matching enabled, then a default GUI rendered in 1080 at 50Hz makes sense as it avoids constant 'HDMI bonks' as your TV switches from 60Hz to 50Hz etc.

    interesting


    I just got pi 5 as decided to want smoother UI experience

    I cant power off the Pi 5 using remote though. Using media player keys and flirc.

    What happens if you navigate to the power menu and select Power Off, or map S to a key (that's the shortcut to bring up the Power Off menu)?

    I've had no problems switching my Pi 5 off via those routes, and then pressing the Pi5's power button (!) switches it back on again!.

    There's a config.txt entry you can enter that massively reduces current draw in shutdown (it's not - or wasn't - on by default as it can cause problems with some HATs because of which power is removed and which remains in that mode.)

    fuzzy

    Do you mean that it's clear that there's horizontal chroma subsampling (i.e. the text is aliasy/jaggy/soft)?

    If so - wouldn't a chroma grating, multiburst or zone plate be a better test for 4:2:2 vs 4:4:4/RGB chroma?

    As others have suggested - what your devices EDID states support for and how your Pi's output is configured can play a part too.

    For 2160p50/60 output modes HDMI 2.0 supports 4:4:4/RGB output at 8-bit only (which isn't suitable for HDR 10-bit video - or SDR 10-bit for that matter), and I think - by default - the Pi will thus prefer HDR-friendly 4:2:2 12-bit output modes at 2160p50/60 if an option.

    For 2160p24/25/30 (2160p25/30 aren't universally supported by displays) and lower resolutions you can run 4:4:4/RGB at higher bit depths - so your output refresh rate and resolution can play a part in deciding whether 4:4:4/RGB or 4:2:2 output is used ?

    Switching to AUX2 on my Denon AVR-X3600H has not solved this problem.

    I have just added hdmi_force_hotplug=1 to config.txt and will see what that does.

    Is the AUX 2 input on your X3600H HDMI 2.1 or HDMI 2.0? (i.e. does it support 4K/120 and 8K/60?)

    (If all of the inputs on your X3600H are the same that would explain the lack of difference. My previous X2400H, which was HDMI 2.0a only - and limited to 4K/60 and no 8K - exhibited very odd behaviour with LE on a Pi 4B/5)

    For info - I'm running my Pi 5 4GB into my Denon X2800H (non-DAB) and an LC C3 via an EZCOO remote controlled HDMI 2.1 (i.e. 48Gbs, not 18Gbs) switch connected to Aux 2 - one of the HDMI 2.1 ports and so far have no problems. I've not changed my config.txt file

    (Denon reduced the number of HDMI inputs on their newer AVRs so I'm having to upstream switch as I've run out)

    noggin https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar contains ^ this patch based on information from https://github.com/bluez/bluez/issues/696 and https://github.com/bluez/bluez/is…ment-1854599254 which reads like the same issue.


    Thanks for this chewitt - using the above patched tar I can trust and connect using the LE add-on (though I initially used bluetoothctl to connect to test) - and so far it seems to work - no constant nags for a PIN. (No need to pair in the add-on or bluetoothctl but the controller does need to be in pairing mode - SELECT+ENTER held down gets it into pairing mode.)