Posts by noggin

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

Quote from chewitt

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.

Quote from Nekromantik

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

Quote from Nekromantik

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 ?

Quote from chewitt

We loathe Argon cases but whatever you like

Glad it's not just me. Superficially they look like a great solution (IR receiver, integrated fan, nice arrangement with all IO on the back etc.)

However I lost countless hours to HDMI connectivity issues - all ended up being caused by poor quality HDMI extenders in the cases...

Quote from Nekromantik

easiest way to test is put this file on pi and view on TV

https://i807.photobucket.com/albums/yy352/f…e-rgb-1080p.png

if the red and magenta columns are not clear then it does not support it

Could you define 'not clear'?

Quote from tomstephens89

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)

Quote from andirama

PS: I didnt tested CEC so far, because i always use a Harmony One as Remote for all Devices and thus i dont need CEC.

When you said you've not tested CEC - can I check that means you have CEC disabled on the Pi and other devices - or you've just not tested remote control pass-through (which is a tiny part of CEC)?

Quote from chewitt

Diff

diff --git a/packages/network/bluez/package.mk b/packages/network/bluez/package.mk
index 9170f27418..0dd5ebef4d 100644
--- a/packages/network/bluez/package.mk
+++ b/packages/network/bluez/package.mk
@@ -62,6 +62,8 @@ post_makeinstall_target() {
         -e "s|^#\[Policy\]|\[Policy\]|g" \
         -e "s|^#AutoEnable.*|AutoEnable=true|g" \
         -e "s|^#JustWorksRepairing.*|JustWorksRepairing=always|g"
+    echo "[General]" > ${INSTALL}/etc/bluetooth/input.conf
+    echo "ClassicBondedOnly=false" >> ${INSTALL}/etc/bluetooth/input.conf
 
   mkdir -p ${INSTALL}/usr/share/services
     cp -P ${PKG_DIR}/default.d/*.conf ${INSTALL}/usr/share/services

Display More

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

I'm having the same issue trying to pair a PS3 BD Remote on a Pi 5 running LE 12 nightly from 20240106. The PS3 BD remote is a second gen one (with TV and AVR IR remote functionality) that used to work fine with older versions of LE (not sure when I last used it) and I can't pair it either via bluetoothctl or the Add On.

(I get prompts for a PIN when the remote tries to connect with the Pi5 - but 0000 and 1234 don't do anything - and I used not to have a PIN prompt I'm sure - it just paired?)

Attempting to pair with 64:D4:BD:6A:C2:62
[bluetooth]# hci0 device_flags_changed: 64:D4:BD:6A:C2:62 (BR/EDR)
[bluetooth]#      supp: 0x00000001  curr: 0x00000000
[bluetooth]# hci0 type 7 discovering off
[bluetooth]# hci0 64:D4:BD:6A:C2:62 type BR/EDR connected eir_len 24
[CHG] Device 64:D4:BD:6A:C2:62 Connected: yes
[BD Remote Control]# hci0 64:D4:BD:6A:C2:62 auth failed with status 0x0b (Rejected)
[BD Remote Control]# Failed to pair: org.bluez.Error.AuthenticationRejected
hci0 64:D4:BD:6A:C2:62 type BR/EDR disconnected with reason 2
[CHG] Device 64:D4:BD:6A:C2:62 Connected: no

I found this reference to an issue https://forums.raspberrypi.com/viewtopic.php?f=28&t=21045

Could it be relevant?

Quote from maxi

On Pi 5 with 12.0-nightly so far no problems reproducing 1080p 4:2:2 h.264/265 video files or streaming, but Hevc UHD feeds not capable, it was supposed to reproduce via HW, but it switches to SW and the CPU goes to the limit...

UHD example...

https://www.mediafire.com/file/i0rv6rukd…+record.ts/file

Mine are all 1080i25 - not 1080p - so also need to be deinterlaced.

Quote from popcornmix

I've just tested and some similar files are playing for me (nighyl LE12 on Pi5):

Code

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 16 s 50 ms
Bit rate : 252 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.004
Stream size : 493 KiB (99%)
Writing library : x264 core 152 r2854 e9a5903
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Color range : Full
Codec configuration box : avcC

Display More

and

Code

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Format Range@L4@Main
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 34 s 76 ms
Bit rate : 1 102 kb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.030
Stream size : 4.48 MiB (70%)
Writing library : x265 3.2.1+1-b5c86a64bbbe:[Linux][GCC 9.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1111039 / frame-threads=5 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x800 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=5 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
Language : English
Color range : Limited
Menus : 3
Codec configuration box : hvcC

Display More

(10-bit, 12-bit, and 444 variants also playing). So I guess there's something different in your files.

Interesting - those are all progressive - mine are interlaced - as will a lot of 4:2:2 media carried on broadcast uplinks (as the bulk of broadcast outside of North America - where 720p59.94 and 1080p59.94 is more of a thing - is 1080i25 or 1080i29.97 - even if it ends up 720p50 for transmission - like in Scandinavia and Germany for instance)