Posts by smp

Quote from Ime81

What can I do?

Buy a playback device that support 4K.

It needs a newer kernel. Use Milhouse nightlies.

Quote from D@nFr0mB3rl1n

replace Kodi Matrix (which would be perfectly fine if it wasn't for this Python dependency error which makes it virtually impossible to install any addon on it why it's disqualified for now) with Leia from the 9.2.2 head

I suspect that it would be much easier to make changes to a Python2 addon so it would be compatible with Kodi Matrix/Python3.

I actually did that with Keymap Editor addon which didn't work with Kodi Matrix.

Quote from polo_joe

Do you use usb dvb tuner?

Yes. Prof 7500.

Quote from Nicolas

Since LE 9 this also happens on X86 systems. If you Copy a File while watching live TV or a recording it will sometimes stutter or even stops for a Second.

I can't reproduce this on my Intel J4105 box. Tried to copy large files over LAN and record while watching live TV. No issues.

I'm trying to enable YCbCr 4:2:2 mode to see if this will fix the issue with Samsung.

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ea07084..cdb0930 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -740,6 +740,8 @@ intel_hdmi_compute_avi_infoframe(struct intel_encoder *encoder,
 
     if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
         frame->colorspace = HDMI_COLORSPACE_YUV420;
+    else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR422)
+        frame->colorspace = HDMI_COLORSPACE_YUV422;
     else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
         frame->colorspace = HDMI_COLORSPACE_YUV444;
     else
@@ -2425,7 +2427,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
     if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
         return -EINVAL;
 
-    pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+    pipe_config->output_format = INTEL_OUTPUT_FORMAT_YCBCR422;
     pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
                              conn_state);

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e61..fc21c66 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -771,6 +771,7 @@ enum intel_output_format {
     INTEL_OUTPUT_FORMAT_INVALID,
     INTEL_OUTPUT_FORMAT_RGB,
     INTEL_OUTPUT_FORMAT_YCBCR420,
+    INTEL_OUTPUT_FORMAT_YCBCR422,
     INTEL_OUTPUT_FORMAT_YCBCR444,
 };

With this patch the colors are wrong (green-ish). Does anyone have an idea how to properly enable 4:2:2 on GLK? Kwiboo ?

Quote from trevevs

A fix for the kernel on the horizon?

Wasn't this fixed in 9.2.2 ?

Quote from csh

Wouldn't in case of bad cable NIC connect at 100Mbps or show some errors/dropped frames?

In your case it looks like it does connect at 100M but for some reason reports 1000M.

I would test it with a short, known good cable before pulling out any cables from the wall

I have the same motherboard with the same Realtek chip. No issues here:

Connecting to host 192.168.88.199, port 5201
[  5] local 192.168.88.7 port 43690 connected to 192.168.88.199 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    404 KBytes
[  5]   1.00-2.00   sec   113 MBytes   945 Mbits/sec    0    424 KBytes
[  5]   2.00-3.00   sec   113 MBytes   945 Mbits/sec    0    540 KBytes
[  5]   3.00-4.00   sec   111 MBytes   935 Mbits/sec   14    460 KBytes
[  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    509 KBytes
[  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    530 KBytes
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec    0    570 KBytes
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0    594 KBytes
[  5]   8.00-9.00   sec   112 MBytes   940 Mbits/sec    0    595 KBytes
[  5]   9.00-10.00  sec   113 MBytes   944 Mbits/sec    0    602 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec   14             sender
[  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver

Try to test with another cable. At Gigabit speed Realtek NICs are very picky with ethernet cables. I've seen some short cat5e cables that work fine at 100M but fail at 1000M.

I'm using Cat6 7.5m cable.

On a Pi3 it was possible to improve this by messing around with "vcgencmd arbiter set arm_uc" command, e.g.:

# vcgencmd arbiter status

# vcgencmd arbiter set arm_uc 12 0

No idea it this is still valid for Pi4.

Quote from Kwiboo

I think LibreELEC-Generic.x86_64-9.80-devel-20200201013402-e776789.img.gz contain a limit to use 8-bit output and if I remember correctly using 4:2:0 50/60hz 8-bit works

Nope, 8-bit does not work too. I actually have to use only 8-bit because of the above mentioned issues with Samsung TVs.

Quote from PKOneTwo

Did you do that?

I only have J4105 and I saw no issues with 4K/60 (non-HDR).

The experimental HDR build is too early to make any conclusions.

4K/24Hz HDR mode works fine but 4K/60Hz HDR mode does not work properly:

Maybe devs know something regarding this issue. Kwiboo ?

I see no reason why the number of EUs would affect the video playback. It can only make a difference when rendering Kodi GUI.

Quote from PKOneTwo

Asking because in this test (Intel NUC7CJYH im Test mit LibreELEC und unter Windows 10) which is running on Kodi in WIndows, the test file did run perfectly on the J5005, but not on the 4005

That same test also says:

Quote

Under LibreELEC all of our test files run smoothly

Quote from TaceN

I need to get hold of version 8.2.5 for Le Potato.

There is no 8.2.5 for Le Potato.

And yes, 9.0.2 is buggy and unusable on Le Potato - live TV issues and also file transfer issues due to this buggy patch.

I figured out how to force YCbCr 4:4:4 instead of RGB:

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 93ac0f2..6336b4b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2418,7 +2418,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
     if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
         return -EINVAL;
 
-    pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+    pipe_config->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
     pipe_config->has_hdmi_sink = !force_dvi && intel_hdmi->has_hdmi_sink;
 
     if (pipe_config->has_hdmi_sink)

Unfortunately this did not fix the Samsung issue. 4K YCbCr 4:4:4 8-bit works fine but "no signal" with 12-bit.

Quote from noggin

That's not correct.

Yeah, it is indeed in the specs. But still the only useful 4:2:0 modes are 8-bit (for displays that don't support > 9Gbps link speed).

Quote from teeedub

Since GLK does not support 10bit modes, does that mean the signal being sent was 12bit?

No, the signal was 8-bit. Despite the popular opinion HDR does not really require 10/12 bit and the TV will switch to HDR/ST.2084 mode when HDR metadata is present.

Quote from teeedub

I wasnt sure how to get more info from the j4105 about what display mode is being used.

Enable DRM debug logging in syslinux.cfg:

drm.debug=0x1e log_buf_len=5M

Then

journalctl -f | grep -E 'color|bpc'