Refresh rate changes causes kodi to hang

Help and Support Raspberry Pi
1

Firstly, many thanks for all your efforts - OSMC/Kodi on the Pi2 is a really cracking media centre. However, I have a fairly unique problem that is causing it to hang regularly so I was wondering if anyone could help?

I have a Pi2 connected through an Onkyo TX-NR626 amp (in video bypass mode) to a Panasonic TX-P50GT60B which supports 1080p CEA modes 5, 16, 20, 31, 32, 33, 34 (according to ‘tvservice -m CEA’).

I boot into 1080p/50 (mode 31) and playing back 50fps files is fine (e.g. DVD rips). However, if I attempt to play back two 24fps film clips (e.g. BluRay rips) in a row then although the TV switches correctly the first and second time (to 24Hz) on the second time the display then remains blank and Kodi hangs (no response to USB remote or Yatse IP remote - reported as “offline”), although occasional blips of audio can be heard so the film is playing in the background. I can ssh in and restart the mediacenter service fine though and Kodi restarts itself successfully with the normal Kodi menu.

I have found that this problem is easily reproduced without video playback by doing the following:
Boot into 1080p/50. In settings change up a refresh rate to 59.94 (TV switches) but then don’t accept the change (TV switches back down again but Kodi still says 59.94 in the dialog). The select the next highest refresh rate mode of 60 (TV switches) → display goes blank and kodi has hung.

With debug logging enabled, I had to change refresh rates a few more time to cause the hang - see debug log (hangs at 08:11:41): http://paste.osmc.io/ovagadigeg.vhdl.

I have tested another Pi2, a new power supply and a new uSD card with no difference so I’m certain it is something peculiar to my particular HDMI chain and components. I have also managed to test with a very similar setup that has a RPi2 through an Onkyo TX-NR1010 amp to the 42" version of the same Panasonic TV and that doesn’t exhibit the same problem.

I have tried playing with config_hdmi_boost with no improvement. Setting hdmi_clock_change_limit=20 didn’t affect the video but the blips of playing audio are slightly longer (upto 1 second). I have also played with hdmi_ignore_edid, hdmi_force_edid_audio and manually setting hdmi_group=1 & hdmi_mode=31 & hdmi_ignore_edid=0xa5000080 but no change. Setting hdmi_safe only permits VGA 59.94 & 60Hz display modes and switching between these doesn’t cause any problems it appears.

In the errored state, the amp shows the input & output video information as 1080p/24Hz (or whatever was selected) but shows the audio flicking quickly from DTS 5.1 (if that was the source) through UNKNOWN to PCM 2.0 and back again - it looks like it’s failing to sync correctly. Note: audio is passed-through from the Pi to the amp for decoding.

As a final test I installed OpenELEC 6 this morning and that behaves exactly the same as OSMC.

I appreciate that it’s probably unique to my situation but I was wondering if anyone can help create a workaround as at the moment I have to turn off “adjust refresh rate” to stop it crashing.

Many thanks in advance!

Jon

2

Maybe you can try hdmi_force_hotplug=1, that worked for me with my AVR problems.

3

This is the key part:

08:11:41  77.103836 T:1958064688   DEBUG: EGL set HDMI mode (1,31)=0 off
08:11:41  77.237244 T:1910502432   DEBUG: EGL tv_service_callback (1,2,0)
08:11:41  77.269356 T:1910502432   DEBUG: EGL tv_service_callback (1,1,31)
08:11:41  77.465881 T:1910502432   DEBUG: EGL tv_service_callback (2,1,31)

Normally I’d expect:

08:11:41  77.103836 T:1958064688   DEBUG: EGL set HDMI mode (1,31)=0 off
08:11:41  77.465881 T:1910502432   DEBUG: EGL tv_service_callback (8,1,31)

I think your display is deasserting/asserting hotplug when the hdmi mode changes (i.e. indicating it has been unplugged/plugged). That isn’t normal behaviour, although I have seen one other similar log.

I think @Theetjuh’s suggestion may well work as it will hide the hotplug deassert/assert.

I actually have an Onkyo TX-SR606 and a Panasonic TX-P50VT50, so pretty similar to your set up, but I don’t get this issue. I’d be interested if it is the TV or AVR that causes this. Can you bypass the AVR and connect Pi directly to the TV and check if it still occurs?

If I were able to reproduce, I imagine I could fix it which would be useful. If you determine it only occurs in certain modes of TV/AVR it might help me reproduce, or at least understand the issue a little better.

4

Looks alot like mine… and I had a TX-NR636 and due to problems now a TX-NR646 :smirk:

If I can help solving these issues, I would love too!
The only problem what I still have is sometimes a shutdown of the AVR when I change from another source to Kodi.

5

@Theetjuh - hdmi_force_hotplug=1 fixed it (or at least worked around it)! Didn’t notice your thread in my searches but now you point it out it probably is the same issue.

@popcornmix:
Spot on.

I bypassed the AVR and connected the Pi directly to the TV and it was fine. I have been unable to isolate it any further than that particular amp. It doesn’t seem to matter which refresh rate you boot into, or which ones you change to, it will always work the first change, and then change back again but after that it could hang with any change.

It does appear to have a timing element to it though as before enabling debug I could reliably get the problem every single time by doing the 50 -> 59.94 -> 50 -> 60 routine but with debug enabled it took a few more iterations.

Can you think of any particular tests to help isolate it further? I can reproduce the hang with ease and I’m more than happy to help.

1 Like
6

I added some code to firmware that “faked” the behaviour I believe your Onkyo does.
Sure enough I got a similar problem as you had reported. The hotplug change message was suppressing the normal HDMI mode change message.

I’ve added a potential fix to the firmware. Can you try it:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_hotplug.zip

Extract the contents to boot partition (the one you see from windows) of sdcard.
Remove hdmi_force_hotplug=1 from config.txt and test.
Post a debug log if it is not fixed.

7

That new firmware fixed it - thanks!

I removed the force_hotplug setting, rebooted and confirmed it hung after a few refresh rate changes. I then extracted the firmware into /boot and rebooted. This time I extensively tested many many refresh rate changes and then playing back content of all fps and it was all good. Just for good measure I replaced with the old firmware and once again demonstrated it hung.

Great stuff, any idea when that fix might make it into a official release?

Many thanks for your time @popcornmix - much appreciated.

Jon

8

Thanks for testing.
It should be pushed to our firmware release github within the next week.
It’s up to Sam when he bumps, but he normally updates quite quickly.

9

Sweet, I’ll try to test it tomorrow as well :+1:

10

And I finaly had time to enable debug for the issue.
Here are my debug logs: http://paste.osmc.io/xuzodobute

Hope you can find anything wrong @popcornmix

11

I guess this is a CEC issue? Does disabling CEC avoid the issue?
What other CEC devices do you have attached to TV/receiver? Can you disconnect (or at least disable CEC) all other devices and see if the issue still occurs?

12

I have disabled CEC and it didn’t happen now, tried for atleast 20 times…

The Pi is directly connected to my Onkyo TX-NR646 receiver.
I just got a new tv, a Sony KD-65X8505C, but it happend with my previous Sony KDL-40W5500 also.
My PlayStation 3 and 4 are mostly offline.
CEC is enabled on all.

13

As soon as the new firmware is available it will be made available as an OSMC update

Sam

1 Like
14

Nice, I have enabled CEC again, since my wife can’t live without it, so hopefully there comes a solution to the poweroff of my receiver…

15

I’d like to know if the issue is caused by an incompatibility between cec of different devices.

16

I could unplug the PS3 and 4, but that leaves the RPi, TV and AVR with CEC enabled.
Then see if the AVR still powers off (with debug on)?

17

Yes. Unplug or disable all other devices that use CEC except Pi, receiver and TV.

18

Unplugged all except, TV and RPi from the AVR, immediately happend after second try.
So not another device it seems…

19

This is beyond my knowledge. I’d suggest enabling debug logging and CEC component specific logging.
Catch the AVR being powered off unwantedly. Create an issue here:

20

Made new debug log: http://paste.osmc.io/irimuronit (first time)
And after that another: http://paste.osmc.io/inituqeqer (second time)

I made a ticket: Switching to my RPi2 powers off my AVR · Issue #186 · Pulse-Eight/libcec · GitHub

Thanks for all your help!