[TESTING] Linux 4.9 kernel and improved video stack for Vero 4K / 4K +

With the “new” 27 revision everything works back fine here.
I had to reboot twice here.
Thanks for the fast fix! :ok_hand:t2:

This is the correct kernel version, yes.

1 Like

Reboot and it should be solved. If it isn’t, some logs will help

Sam

1 Like

Sam, if you are referring to the blank screen issues with my old Marantz NR1603, the random blank screens are still an issue, having just applied the very latest updates. I think my new NR1711 is ok.

A reboot did the trick. Thanks.

I will never stop being amazed by the support here. It’s just a testing version, being inherently buggy and unstable. And yet, the issues we have are fixed in lightning speed. I just came to report problems playing media and TV after yesterday’s update just to find fix is already online and all I have to do is update again. Now everything working smooth as before, thank you.

7 Likes

Greenvideo happened again, I did check and my video is also 23.976 FPS:

  1. debug log on
  2. cat /sys/class/video/dump_reg
  3. grab-logs -A
    Logs available at https://paste.osmc.tv/evijacuqaf
  4. reboot
  5. cat /sys/class/video/dump_reg
  6. grab-logs -A
    Logs available at https://paste.osmc.tv/obavuturig
2 Likes

this happened to me last night when seeking in a 4K mkv file. First couple of seeks were fine, then I got a green screen, and I had to pull the power to the Vero to recover. All 4.9 updates had been applied as of late on 21st Nov UK time.

Hi guys, by when can we expect this branch to make it into the official release?

Cheers,
Frank

So I’ve been doing more testing with my Marantz NR1711. I have recently been experiencing occasional blank-screen issues when stopping playback on my 4.9 Vero. Sometimes the screen might be blank after other source-switching events. Nowhere near as bad as my old NR1603 (since March OSMC), but mildly annoying. Typically switching input back and forth fixes it.

I just added “phydelay=0” to /usr/bin/mediacenter, and the Vero/NR1711 combo seems rock-solid now. I have pushed it through all sorts of stop/start events, source switches etc, and it feels really robust. Not sure if this is premature, but will keep an eye on it with this setting.

Thanks for confirming that you’ve worked out how to use the phydelay parameter.
Just to confirm that it is working as expected, you could also enable debug logging, and look for this line:

Waiting %d milliseconds for PHY toggling

This will let you see if your changes are taking effect.

In previous builds, there was no delay between TMDS toggling whatsoever, and in this build, I introduced a delay a 100ms (simply as a guess).

It would be good if you could test with your other AVR, so see if there is a value which improves things for the receiver.

If we can’t find good values soon, I’ll likely keep the value at 0, but keep the option for this to be adjusted manually.

Thanks

Sam

There’s no firm ETA for this yet as there is still quite a lot that needs to be done.

I think a few things changed for me at the same time, my new AVR just ran a firmware update too. I think the delay did not help in my case, I can tinker with this more next weekend. I still occasionally get an occasional blank screen, e.g. let a film play out to the end, the screen can blank and the GUI does not appear. Switching input fixes it. But it’s only an occasional thing.

A minor, but nonetheless irritating, issue that appeared a while back: when I’m playing a 720x480 video and pause it for a while (20 seconds maybe), when I start playback again, the screen turns black for several seconds and the sound cuts out - as if it’s renegotiating the HDMI connection.

If, while the screen is black, I skip back 10 seconds, it takes an annoyingly long time for the sound to come back up - 10 or 15 seconds sometimes.

Some logs: https://paste.osmc.tv/uguxavoluw

I’m using hardware decoding of an h.264 video, incidentally.

2020-11-22 22:01:58.499 T:4028621024 DEBUG: ActiveAE::SyncStream - average error 1.155843, last average error: 260.236696

Shity encode – requires a while to seek backwards for keyframe
Not uncommon in the lower res days…

AVI/XVID was the worst…

Why does it make a difference how long it’s paused for, then? Pause it for 5-10 seconds and it carries on happily; pause it for 20 seconds and I get several seconds of black screen when resuming.

Because it will keep feeding the buffer until it is full.

If you send a sample, the behaviour can probably be improved, but it will be low on the list at this point.

It had hit me two more times on the same evening, I just did not post additional logs at it seems not to be any more help.

May as well, I guess. Is there an upload link?

Try https://videosam.pl/