Posts by noggin

Quote from boragthung

All channels on Freesat devices have OpenSky listed as epg source - none of them mention freesat as source, even though this is the predominant mux I schedule (11425H). I will experiment by removing the sky collector on my docker - but suspect I will have missing data for some channels.

I just use the Open TV Sky UK EPG collector on my current main recording instance - which is using 4 tuners of an 8 tuner SAT>IP server, and that instance also has Freeview enabled for a Silicon Dust Quad DVB-T/T2 tuner. I have used the Freesat EPG source in the past - but my current set-up has been using Sky EPG data since I started from scratch. On a previous install I had some issues with missing EPG data from the Freesat EPG after a while, which is why I re-started from scratch with a new install running with the Sky EPG (This main TV Headend recording server is running on a Debian OS with OpenMediaVault on an cheap Celeron x86 box with an 8TB USB 3 hard drive connected. However I also have a pair of Pi 4s running Raspberry Pi OS that are able to use other tuners on the same DVB-T/T2 and S/S2 network tuners - and both are running fine).

I use the BSkyB Bouquet 5 - HD England : London to allocate logical/local channel numbers from the Sky EPG.

I only have the PSB3 mux in my set-up for Freeview (I sometimes want to record both Freeview HD and Freesat HD variants of the same broadcast) currently - and the EPG source entries for that, like yours, are blank.

I've manually renumbered the Freeview HD channel numbers to the 1xxx range and renamed them to have DVB-T2 in their titles so I can explicitly schedule DVB-T2 recordings.

I have no obviously missing EPG data - though I used to suffer from missing channel listings data occasionally (usually when they had changed transponder)

Quote from boragthung

I was not totally sure of the precedence of collector that should be set to keep the latest epg and if one will totally overwrite the information collected by another or just update it? If you understand what I mean? So if I have collected the 7 day epg with Freesat, then a later run collects it with Open Sky, does that Sky collection totally overwrite the Freesat collection or just fill in the gaps? I only have the Sky one enabled as well as the Freesat as I find info from some channels will be missing without it.

I've wondered about this as sometimes I get series/episode info in the TVH gui then at a later point I don't so I have suspected if one collector has this info it could be being overwritten by the one that doesn't.

I would only run Sky or Freesat EPG collectors - not both - or if you do have both - chose one EPG source per channel.

Quote from boragthung

So you think it would be a good idea to enable the epg running state option? The current setting has epg update window set at 24 hours. Should this be left at that or altered?

On my Freeview box I have OTA settings:

45 4 * * *
15 14 * * *
45 18 * * *

The internal grabber cron is:

4 */12 * * *

and I have epg saved to disc every hour.

I always have a 7 day epg - the only problem is when things overun. A great example is when Wimbledon is on - this can cause delays, complete programme changes and even complete channel changes of programmes. I'm not sure how to get a 'dynamic' epg to cover these type of problems.

Display More

You misunderstand me - I use the accurate recording option of 'Use EPG Running State' in the Recording Config - which uses the triggers for Rec start and stop in the EITpf DVB data.

I have used TV Headend for 10+ years and never touched the cron settings - they're all on the defaults. The defaults have always downloaded the Freeview/Freeview HD and Freesat or Sky EPGs OK for me - though I've not got recordings regularly set for shows that are likely to be disrupted by sport (like the BBC Ten O'Clock News for instance)

Wimbledon is going to be an issue as shows switch channel and the EPG EITpf stuff doesn't cope with that (Freeview+ and Sky+ also struggle with channel switches for the same reason) I think that's a known issue. AutoRecs might work if the EPG is updated but I don't think you can run an EPG update every minute to catch those very last minute EPG changes (as opposed to EITpf changes) - but Wimbledon is a known issue.

However football delays and overruns like the Eurovision Song Contest are often handled OK from memory.

Quote from boragthung

The thinking here is that maybe the EIT Now/Next might update to cover programme overruns while recording. It doesn't seem to work like that though from what I have seen. I know there is epg running state in recording config, but I don't trust broadcasters to use that properly. This dates back to my experience with a VHS recorder (in the1990's) which had PDC (Programme delivery control). This was never implemented correctly and it often cut off the very beginning or end of a programme, which defeats the purpose of it.

The main BBC, ITV, C4 and C5 channels - all played out by Red Bee Media - do correctly update the present/following (aka EITpf 'Now/Next') data that drives accurate recording in TV Headend on Sky, Freesat and Freeview platforms. (Virgin's platform doesn't support it).

For BBC channels the EITpf accurate recording triggers follow the same rules as the old VHS PDC used to, and is updated to start recording on the BBC ident before the show (so any content warnings are recorded), and to record the item in the junction after the show too (such as a pointer to the BBC's Action Line support service if the show has contained content that could trigger some people to seek support - such as domestic abuse, addiction portrayals etc.)

It works pretty well in my experience - though for non-Red Bee Channels it's a bit more hit and miss - though most of them are clock-time linked anyway (Talking Pictures isn't)

Quote from DeShizz

I've seen these too. The only reason I can assume this is done is to avoid the "Green and Purple" issue when playing DV Profile 5 files on non-DV hardware but still get DV on licensed hardrware. This exact issue crops up with the Pi as well since its not licensed for DV.

Yes - though in effect you're watching a YCrCb PQ PQ10 (i.e. HDR10/10+ but ignoring the metadata) stream with DV Metadata RPUs from an ICtCp DV Profile 5 stream grafted in to create a fake Hybrid DV stream (like a UHD BD with the MEL/FEL ignored).

There's no guarantee that the RPUs are correct for the PQ10 output stream (they are designed for a render in a different colour space - and there's no guarantee the HDR10/HDR10+ render will be changed correctly by metadata designed for a different output colour space) - so although the Dolby Vision light might come on - there's no guarantee you're seeing any improvement over the static HDR10 or dynamic HDR10+ metadata - and in fact you might be seeing something worse - but hey, the DV logo has appeared...

Quote from DeShizz

Interesting you posted this when you did, I notice that they have released their Omega Stable build today which seems to add a few more options:

"Dolby Vision will be supported on Amlogic-ne and Amlogic-ng with Kodi Omega on certain Amlogic devices like Homatics/Dune R 4K Plus, RockTek G2 or Nokia 8010. Other devices on Amlogic-ng like Ugoos AM6+ or Minix NEO U22-XJ (Max) equiped with S922X-J will support Dolby Vision with profile 7 FEL as well."

(Quoting from their release notes)

Seems like DV is a high priority featureset for CoreELEC. But their target market seems to be limited to Amlogic only, so I guess it makes sense for them as they are not putting in development effort on other platforms.

CoreElec's DV support (at least in the -ne branch) requires an Android box and Android OS that already has DV support - as it uses the Android DV code in the Android install (which has to remain on the eMMC storage) on-the-fly called from the CoreElec code. CoreElec itself doesn't do the DV decoding - it relies on the Android code (which it doesn't redistribute)

The two builds of CoreElec for the two supported platforms have differing support for dual layer decoding - the -ne is single layer, the -ng is dual layer, and they run on different platforms. This limitation is apparently an AMLogic SDK thing - as the dual-layer decode on the -ne platform-supported devices is currently broken?

If the OP doesn't have a USB nvME interface then presumably you could boot into Raspberry OS from a uSD card or USB stick and then write the LibreElec image to the PCI-E connected NVMe drive from within Raspberry Pi OS assuming the Raspberry Pi OS 'sees' it. Once you make sure the EPROM bootloader has the PCI-E NVMe as a boot option you can then reboot to LE without the uSD or USB device installed on the Pi?

I've not use LibreElec on a PCI-E NVMe Pi 5 - but that's how I installed Raspberry Pi OS and Ubuntu on two different Pi 5s with NVMe HATs.

Yes - one thing to be aware of and which I should have mentioned is that on many TVs (including my LG OLED and previous Sony FALD LCD) SDR, HDR10/HDR10+/HLG and Dolby Vision sources will often trigger separate display settings for each type of source - plus you wouldn't expect Dolby Vision and HDR10 versions of the same drama to look identical. (The Pi 5 doesn't do Dolby Vision). You often have far less control of settings on Dolby Vision content for instance.

There are also some dodgy, pirated, 'Hybrid' versions of dramas kicking around apparently. These take a downloaded HDR10 stream from an OTT streaming service, but then graft on Dolby Vision Metadata RPUs from a separate Dolby Vision native download of the same show from that service, to create a file that plays back as HDR10 on non-DV-compatible devices, but will trigger Dolby Vision logos on some Dolby Vision replay solutions (though the RPUs aren't meant for the YCbCr HDR10 stream and instead designed for an ICtCp encoded stream...)

Quote from Wolfpig

The TV is not creating the same level of brightness/saturation/color on sdr content when that is displayed with hdr as it most likely supports only a low level hdr on sdr content (mostly happens on lcd/led screens, oleds are far better to get a good sdr on hdr picture).

So the problem with the washed out colors is normal and might be lessend by adjusting stuff like brightness when it is displayed (but would also affect hdr as you change it in that mode).

You might search the net if people might have posted settings guides for that TV which you might like to try.

BTW. Switching the color range to full was needed as hdr formats like dolby vision only work with the enhanced color space.

Not sure what you are trying to say here. SDR is SDR - sure you can chose to process it and push it into the HDR range - and many people do. This will make the picture look bright - but it will then mean an SDR signal will be displayed far brighter than the SDR portion of an HDR10/PQ signal.

PQ ST.2084 HDR (i.e. HDR10) is based on an 'absolute' HDR standard that maps specific video levels to absolute pixel light output - so a video level that deliever 100 nits is 100 nits on any ST.2084 PQ (aka HDR10) display unless that display is not following the ST.2084 PQ curve and is being overridden. Displays differ in their max brightness - and in those casese the PQ curve is tone-mapped to mitigate the max brightness limitations, and obviously there are better and worse performers at black level.

However 100 nits is a 100 nits (and is represented by 51.9% of full-range in a PQ ST.2084 signal) - any display correctly displaying the SDR portion of an HDR signal will deliver this 51.9% signal as 100 nits light level whatever the screen tech is if it is correctly meeting the standard PQ specs.

Some TVs will use processing that means they no longer track the PQ/ST.2084 curve correctly to let you make the picture in HDR brighter or darker - some in their 'Cinema' or 'Movie' modes won't.

I recently switched from a Sony FALD LCD to an LG C3 OLED with both correctly calibrated and the subjective performance was similar for both SDR and HDR content in picture brightness terms watching the same content - though the OLED clearly did better with blacks and there was no FALD backlight booming, and the OLED overall delivers a nice clean picture.

This is a really good primer on HDR PQ and HLG and SDR and explains a lot about why HDR can sometimes appear 'dark'. It's written by a former colleague who is an expert on both display calibration and motion picture colour science.

PQ HDR & HLG

Understanding PQ HDR and HLG

www.lightillusion.com

AIUI HDR10 may use 1-1023 rather than 64-940 (aka 16-235 in 8-bit) level space - which is why leaving a TV on Automatic rather than Full or Limited may make the most sense.

Quote from boragthung

I have set up an external (powered) HDD to replace the usb flash stick and the latest recording had no problems. I shall set up some more to see how it goes. I will also set up a swap file on that now. The Rpi power is the official one to be used (from PiHut) and I have the TVHat case and a flirc. I have always only used the Freeview epg module, disabling the others.

If you have the "Over the air : UK : Freeview" EPG enabled then you should get clear EPG data for the HD channels.

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 ***

Quote from boragthung

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.

Quote from boragthung

I recorded a 1 hour program off Blaze (SD) yesterday and checking on it now shows no problems with that recording. I have set up a couple more recordings to see what happens - a 30 minute HD programme and a 100 minute SD programme.

One thing I noticed looking at the .ts files with mediainfo there is information regarding the times of programmes:

Excerpt from last successful (SD Channel) recording:

Service name : Blaze
Service type : MPEG-2 HD digital television
2024-04-03 00:00:00 UTC : en:Swamp Mysteries With Troy... / en:...Landry: Hogzilla: Troy searches for a monster threatening residents of a small Texas community. / show/game show / / 01:00:00 /
2024-04-03 01:00:00 UTC : en:Blaze is back at 5am / en: / show/game show / / 03:00:00 /

*Note All in clear text.

Compared to a bad recording made previous (HD Channel):

Service name : Channel 5 HD
Service type : MPEG-2 HD digital television
2024-03-31 01:00:00 UTC : en:ËX"ÄòR»'á¸ììÙ»J_¡ / en:- / show/game show / / 02:00:00 /
2024-03-31 03:00:00 UTC : en:«ÃÖæ³{èSð¯FËà / en:¶þ}Ý>[vTpV-m6})ùtõ=ÎðvWiè;×°9È×k6ìqó½q靈¾vì㸮ZKÎ×eƪå©xvé'ìFlxq: [à / social/political issues/economics / / 00:45:00 /
2024-03-31 03:45:00 UTC : en:Êr¨9N¾ýµÚ£©+¹à / en:qL¹lÓö{:c¡Ïx¿T£Ü#vÆþ¶=fÒ"¿³$^ñÎðvÇAëüª3ö{:c·¯¹K}$¾ªþ\/ÑÛU/ÓJ]QÞkâÀ¨o / social/political issues/economics / / 00:50:00 /

*Note the strange mixture of text. I don't know if this is some encryption (but all channels are free to air), or possibly corruption?

Display More

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.

Quote from Zygmunt

Hello everybody
I couldn't leave this problem unsolved, so I returned to this thread to check for new info.
Hiassoft, you inspired me to further investigation writing: "Did you enable "Ultra HD Deep Colour" in your TV's HDMI port settings? If not then the PC will likely use 4:2:0 to output 4kp60 and RPi4 will be limited to 4kp30 as it doesn't support 4:2:0."
I couldn’t find "Ultra HD Deep Colour" in my Hisense 43A65H settings, but I checked display info on my PC (Intel N5105) and found that output is 2160p/60 YCbCr420. I couldn't find any info about color depth output from N5105.

I connected PC to LG 32UL500-W, which has a maximum refresh rate of 60Hz on HDMI input. (HDMI 2.0). The max I could get was 2160p/60 YCbCr420.
Where is a limit? In PC or LG monitor?
Than I connected PC to Denon X7200WA (connected to old 6040UB projector) and got 2160p/60 YCbCr420. I didn't expect any better result because 6040UB doesn't accept signals over 2160p/60 YCbCr420.

Now it is time for RPi4 and RPi5
RPi4.
I added "hdmi_enable_4kp60=1" to config.txt just after hdmi_ignore_cec_init=1
After connecting to Hisense 43A65H, RPi4 didn't let me go over 30Hz.
So there are questions:
Does Hisense 43A65H really accept 2160/60 4:4:4 and 4:2:2? It does not. (Or there is EDID problem).

Connected to LG 32UL500-W. RPi4 let me set 60Hz. It means that "hdmi_enable_4kp60=1" works, Hisense 43A65H has a problem with RPi and my PC can not send 2160/60 4:2:2 only 4:2:0.
After connecting to Denon with projector OFF and only LG monitor connected, I could set RPi4 to 60Hz as well. It means that LG 32UL500-W accepts 4:2:2.

Now RPi5
After connecting to Hisense 43A65H, RPi5 didn't let me go over 30Hz exactly like RPi4.
When connected to LG 32UL500-W, RPi5 let me go to 60Hz without a problem.
I connected RPi5 to Denon/LG monitor. No picture at all. I replaced RPi5 by RPi4 - and there is a picture. I connected RPi5 - no picture. Weird. Why RPi4 works but RPi5 doesn't?

In next step I was testing RPi4 and RPi5 connected directly to LG monitor. I could play my 2160p/60 fps videos H.265 smoothly, but 2160p/60 fps H.264 videos are choppy on both players.

Last test - 1080p movies. Both players play 1080p H264 without a problem.
RPi4 has a problem with 1080p VC-1, but RPi5 plays them smoothly.

Thank you all of you for your help.

Display More

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.

Quote from HiassofT

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?

Quote from Zygmunt

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.

Quote from kapqa

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?)