September Update - Green Screens

Help and Support
1

I updated to the September update yesterday. My previous one was March update.

Ever since updating I am experience a lot of green screen crashes as well as a few blue sad smiley screens. With March update I used to see sad smiley crashes every now and then but this green screen stuff is definitely showing up after September update. Usually happens when I try to skip through the video. Stopping and playing any other video and I get same result. It requires a reboot for the issue to go away until the next time it happens again.

Here are the logs… hopefully it will contain something pointing towards the issue.

Logs: https://paste.osmc.tv/vinonomiho

Another logs (might be cleaner/better than the one above): https://paste.osmc.tv/vesefovagi

Thanks
MR

1 Like
2

Hi,

Thanks for the logs.

I can see a decoder error

Sep 19 20:43:04 osmc kernel: [vdec_kpi][vh265_isr_thread_fn] First I frame coming.
Sep 19 20:43:04 osmc kernel: [0]VH265: output first frame
Sep 19 20:43:04 osmc kernel: [pts_kpi] first lookup vpts=0x51c9f6c offset:0x88
Sep 19 20:43:04 osmc kernel: [vdec_kpi][post_video_frame] First I frame decoded.
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 0th poc (54) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 1th poc (50) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 2th poc (45) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 3th poc (41) not in list0
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 0th poc (59) has error
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 1th poc (54) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 2th poc (50) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 3th poc (41) not in list0
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 0th poc (59) has error
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 1th poc (54) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 2th poc (50) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 3th poc (41) not in list0
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 0th poc (59) has error
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 1th poc (54) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 2th poc (50) not in list0
Sep 19 20:43:04 osmc kernel: [0]Error config_mc_buffer, 3th poc (41) not in list0
Sep 19 20:43:04 osmc kernel: [0]cur lcu idx = 0, (total 510), set error_mark

If you avoid seeking, is the issue reproducible?
Have you tried playing an affected file from local storage?

3

It’s not one single video file this happens on. I have tried with multiple files. Seems to happen when I try to skip forward/backwards or skip chapters. Once it happens on a video file all the files played after that show the same green screen (with audio playing in the background) until I reboot. Did not have the this issue with March version on these files. Will play a completely different set of files and put up the logs here in a bit once this error happens.

Files are played via NFS using autoFS. Have tried playing on a kodi installation on windows and have not seen this issue.

Also see some other posts with similar issues so it does not seem to be a file-specific or an isolated issue. I am able to reproduce the issue quite easily on seemingly any file.

Logs after reproducing issue using completely different and random files - not used for logs before:

https://paste.osmc.tv/bahenifomo

Reproduced using a file that I know that I have 100% played before without issues on earlier versions:
https://paste.osmc.tv/kusizavose

Another edit after couple of hours:
So I sat through two full episodes without seeking/skipping and have not seen any green screen issue. Could possibly be the skipping/seeking that causes it.

4

Can you reboot your Vero and connect to it using ssh? Then enter the following command before playing a h.265/hevc clip:

echo 1 | sudo tee /sys/module/amvdec_h265/parameters/mmu_enable_force

Does that fix the issue?

5

Let me give it a try… should I keep debug logging enabled for this? And what exactly does this cmd do?

Tried with the cmd above. Haven’t seen the issue with the cmd as yet but will keep trying to reproduce it.

6

Thanks for testing. That command doesn’t really fix that issue, but it helps me to narrow it down. No debug logs necessary at this time.

7

I’ve also put a new kernel in staging with this parameter enabled by default.

To test this update:

  1. Login via the command line
  2. Run the following command to add the staging repository:
    echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
  3. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  4. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.

This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.

Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.

8

There’s also another issue that I keep seeing when skipping through a video using right left buttons on the remote. When I press the said buttons sometimes we see greenish looking artifacts on the screen - usually on the lower part of the screen just above the seek bar but sometimes a bit higher up as well. I tried playing through without seek and video doesn’t have any such artifacts/glitches. Not sure if these two issues are related though. Also not sure if these glitches are recorded in the logs or not.

9

Have you tried updating as advised above?

10

We’ve long been aware of that issue, but don’t have any clues as to how this could be fixed. It doesn’t break playback and seems to be purely cosmetic, so it shouldn’t impact usability. It’s on the list of issues and we’ll fix it as soon as we’ve come up with an approach to this issue :+1:t2:

13

Not yet but will do it later today and test various video files to see if I can reproduce the issue. I am quite certain it’s linked to seeking forward or backward and/or chapter skip as i did not see this issue during about 2 hour playback of a couple of episodes last night where I did not skip/seek.

14

I switched to the testing branch as you advised. Have not been able to reproduce the issue as yet - tried a whole bunch of files.
Also see a possible reduction in the on-screen green artifacts/glitches when skipping through a video file. It could be just a placebo effect but it feels that it’s happening less frequently than what I was seeing earlier.

15

I have same issue but mine was present in March. Was hoping this update would fix but it did occur last night. Seems to only happen when I skip forward/backward a lot on HEVC clips.

16

I never saw this green screen thing prior to September update.

@sam_nazarko - this only impacts HEVC files (x265)? I briefly tried a few x264 ones but was not able to reproduce - but it was a small sample size.

17

Yes - only HEVC will be impacted.

18

Have you tried the solution proposed above? I believe it solves the matter.

19

I am having the same issue on both Vero’s.
All I could add is that once it happens, all subsequent videos will be a green screen until a reboot.

I’ll try the fix …

20

Please try the fix and report back

Best

Sam

21

I also had this issue. After rebooting I wasn’t able to immediately replicate. Regardless, I’ve ran echo 1 | sudo tee /sys/module/amvdec_h265/parameters/mmu_enable_force and will continue to test it and report back.

22

If you update to the staging repository as suggested above, the issue will be fixed.

Sam