[Solved] Vero 4K+ not resuming correctly after suspend

Hi.

I am running into a suspend / resume issue with my 4K+.

Details:

OSMC running Kodi 18.3-RC1
Compiled 2019-05-21

Settings/System > Power saving >
Shutdown function timer = 90 mins
Shutdown function = Suspend

The device appears to suspend correctly after 90 mins and I see a red light on the front LED.

When I click the remote, it seems to wake up, but will not take any further input from the remote. I tried to remove the re-plug in the usb dongle for the remote.

After waiting this out for about 10 mins, I ssh’d into the machine and rebooted.

Not sure why the device is not resuming correctly, and not sure what further info I can provide.

Thanks for any pointers / assistance to help solve this.

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

  • enable debug logging at settings->system->logging

  • reboot the OSMC device

  • reproduce the issue

  • upload the log set either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A

  • publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

Thanks. I have enabled the logs and will report back when I can reproduce.

Hi again.

Here is a link to the (entire) kodi.log

It stopped right as I pushed the home button.

ssh into the device works.

only thing I notice is a load average over
screenshot

Have not rebooted the device yet if there is any additional info I can provide.

Please use grab-logs -A and provide the URL instead of using external pages

https://paste.osmc.tv/ezibiqixas

Maybe it’s a screensaver problem?

2019-06-08 12:14:21.730 T:4064330464   DEBUG: CAnnouncementManager - Announcement: OnScreensaverActivated from xbmc
2019-06-08 12:14:21.731 T:4064333824   DEBUG: using python screensaver add-on screensaver.digitalclock
2019-06-08 12:14:21.731 T:4064330464   DEBUG: GOT ANNOUNCEMENT, type: 4, from xbmc, message OnScreensaverActivated

Also I assume you try to control via CEC or which remote are you using?

Not trying to use CEC, using the osmc remote that was shipped with the vero 4k+ unit.

Normally I power up the TV first, then wait a few seconds and power up the Vero device.

I will disable any screensaver and see if this fixes the issue, and report back.

I am having similar issues, also using a screensaver.
But it doesn’t happen all times, so no clue yet what is going on unfortunately.

No longer happening on both my 4K+ units after I disabled the screensaver. I went to the default installed “dim” and “black screen” screensaver options on each unit, and this does not cause the freeze issue.

Solved for me … ty fzinken for the info / pointers :slight_smile:

Same here. My Vero 4k+ looks like not getting input from remote control after resuming from suspend. I followed tnedor’s suggestion to disable screen saver or to switch to “dim” or “black” screen saver. Resuming from suspend works now.
I think there is an issue with Picture Slideshow Screensaver.

@tnedor – were you also using this?

Sam

If Picture Slideshow operates in the same manner as Artist Slideshow, then this is posibly a Kodi limitation/issue.

Nope

I think I was using the Google Earth Screensaver at the time. Not sure if that uses the same code as the Picture Slideshow Screensaver.

I have had similar trouble, but noticed a possibly relevant log message each time it happens:

kodi.2019-08-07.debug.log:2019-08-07 08:26:38.136 T:4066377728 ERROR: CPythonInvoker(9, /home/osmc/.kodi/addons/screensaver.picture.slideshow/default.py): script didn’t stop in 5 seconds - let’s kill it

I have also seen the unexpected wakeup after manual suspend, so I am going to quit using manual suspend and see if that avoids triggering this problem.

Keep me posted but I believe the issue is caused by timers