I tried forcing 720p using config.txt and hdmi_mode=4
I also tried hdmi_safe=1
config.txt settings apply to the old, deprecated firmware display driver.
cmdline.txt is the standard linux way of configuring display modes. e.g. see here.
Something like:
video=HDMI-A-1:1280x720@60DAdded to cmdline.txt (on end of same line).
Did you find and read this?
However, I noticed that when viewing such files, the screen goes blue (no signal) for a second and then returns to the connection with the pi, where the file starts flawlessly. This does not happen with H264 encoded files, so I find it a bit strange. Obviously I have never had this issue before, since the pi 3b cannot play H265 content. Any explanation to this?
Does this occur if you disable hw decoding in settings/video?
Is the Pi3 running the same version of LE as the Pi4?
It is more likely a change in behaviour due to different versions.
All the "hdmi_" settings you've mentioned apply to the deprecated firmware display driver.
LE10/11/12 use the kms driver (kernel side) rather than fkms (firmware side) used by LE9.
The kms driver does rely on a fully working hdmi cable (i.e. reporting hotplug and edid correctly).
The fkms driver was more likely to somewhat work with a faulty cable.
As a simple test, connect the Pi4 to the display without an sdcard inserted.
It should show a diagnostic screen, that includes info about hotplug (HPD) and edid.
What does it show?
Are you stopping the video when navigating with kodi?
Do you have "adjust display refresh rate to match video" set to on start/stop?
Ok... But the guide(https://wiki.libreelec.tv/support/update) says it should be a .tar file to update. The only one i found is a .gz one.
That will work fine.
No. There's currently no 3d support.
2. My understanding is that RBP3 doesn't use standard (hardware) video acceleration, and will run worse on newer versions, so the best version to use is 9.2 since that was built pre-4 and has all the specialized video accelerations tricks for RBP built in.
HW acceleration works fine on Pi2/Pi3 for h264, mpeg4, mpeg2 (with licence), VC1 (with licence) with latest kodi.
The only loss compared to 9.2 is hevc decode. That had a heavily software accelerated decoder which used bits of
arm simd, 3d shaders and VPU vector operations. Unfortunately that just wasn't possible to support when moving to
standard linux api (v4l2 and drm).
I'd recommend using the latest LE image, and avoid hevc encodes.
If you need to play hevc, then stick with 9.2.
Try with video=HDMI-A-1:1920x1080@60D
Okay - those logs look identical so the firmware is loading the device tree overlay (called HAT) correctly.
Looking through the kernel log. This is the bad one:
Feb 17 04:10:58.938161 LibreELEC kernel: wm8804 1-003b: Failed to read device ID: -121
Feb 17 04:10:58.938688 LibreELEC kernel: wm8804: probe of 1-003b failed with error -121and this is the good one:
Feb 17 04:10:58.605877 LibreELEC kernel: wm8804 1-003b: revision EThis feels like a hardware issue. You might want to try reaseating the HAT to make sure it's secure,
and perhaps check the soldering looks consistent along the 40 pin header.
<<Do you have "adjust display refresh rate to match video" enabled.>>
It was set off, I changed it to always but it didn't seem to make a difference.
I then thought what happens if I set the display rate to 25fps and its almost perfect. I reset the refresh rate to 30 and rebooted but still jerky. Blundering about the wiki I manage to track down the entry for this and it says always isn't recommended - which of the two remaining is the best choice?
On Start/Stop is usually recommended.
Add "dtdebug=1" to config.txt and post output of "vclog -m" for a working and not working boot.
A debug log would help.
Obvious question is what is the framerate of the video.
Do you have "adjust display refresh rate to match video" enabled.
Does the BENQ monitor support that framerate?
It will affect the video audio too if you are not using passthrough.
If you have this issue with passthrough audio, then there is nothing kodi can do -
the audio is decoded and output by the TV/AVR and kodi has no influence on how it sounds.
Is the audio going over hdmi directly connected to (no AVR) TV?
Is kodi set to 100% volume (it should be - just use TV remote to adjust from there).
2023-05-08 06:40:22.015 T:1112 info <general>: ffmpeg[0x3faf3a8]: [hls] Opening 'crypto+https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306835.ts?m=1683518436' for reading
2023-05-08 06:40:27.980 T:1112 info <general>: ffmpeg[0x3faf3a8]: [hls] Opening 'crypto+https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306836.ts?m=1683518436' for reading
2023-05-08 06:40:36.103 T:1118 info <general>: CVideoPlayerAudio::Process - stream stalled
2023-05-08 06:40:37.950 T:1117 debug <general>: CPtsTracker: pattern lost on diff 79999.000000, number of losses 1
2023-05-08 06:40:37.954 T:1117 debug <general>: CVideoPlayerVideo - Stillframe detected, switching to forced 25.000000 fps
2023-05-08 06:40:42.811 T:1117 debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2023-05-08 06:40:47.996 T:1112 error <general>: ffmpeg[0x3faf3a8]: [tcp] Failed to resolve hostname d2ce82tpc3p734.cloudfront.net: Name or service not known
2023-05-08 06:40:47.996 T:1112 error <general>: ffmpeg[0x3faf3a8]: [crypto] Unable to open resource: https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306836.ts?m=1683518436This is the key part of log. It looks like we are happily reading data from d2ce82tpc3p734.cloudfront.net, geting a chunk every 5 seconds until it fails. It's unable to resolve the hostname (a DNS failure).
I suspect the problem isn't on the LibreELEC device, but somewhere on the local network (router if it handles DNS, but it could be another PC is you are running PiHole or some other DNS server.
Can you try running (on the Pi or any linux machine* on network):
while : ; do ping -c1 d2ce82tpc3p734.cloudfront.net || break; sleep 1; doneIt should run forever but will stop if you get a failure.
(*) ideally a machine that doesn't do DNS address caching.
I know that hardware can't decode all the codecs, but, is my Raspberry Pi faulty? Because I notice that this issue is very random, I mean, if I notice the issue and I rewind some seconds the issue is not visible, but in 5 minutes appears again in other part.
Do you have access to another Pi4? The usual way to provide evidence of a hardware fault is to swap the Pi over (leave sdcard, power supply, display, cables etc unswapped). If problem no longer occurs it is likely hardware. If it still occurs it is software (or located within the unswapped parts).
The fix was here: https://github.com/xbmc/xbmc/pull/23190 but may not have made it into LE.
