Can't wake from sleep after recent update

We did an update a few days ago, and now ever since, when OSMC goes into the dimmed screen mode and sleeps, I can’t wake it. We usually interact with it with an IR remote, that isn’t working to wake it. Nor is the kodi remote app (ios). When using the kodi remote app, I hear the key clicks, but nothing is changing on screen. If I SSH into the box, the shell will open, but after I try to reboot it with sudo reboot now, it just disconnects the SSH session and never reboots. The only way to bring it back to life is pull the power and reboot it that way.

Logs here:
https://paste.osmc.tv/ikipufagur

How are you putting the device to sleep?

It’s doing it on its own. Perhaps sleep isn’t the right word. It’s the dimmed screen that happens on its own after being idle for a while. The recent pattern has been that when we get home after work and go to turn it on, it’s stuck in this state. So typically it’s been idle since we turned off the TV the night before. It’s an old TV with no CEC. We typically just press stop on whatever show the kids are watching and turn off the tv. From there on out, OSMC just does whatever it does when it’s idle.

Right, got you. Does the front LED turn red?

This is a Pi 2. Which side is the front? There’s just the two LEDs, the red one that’s always on and the green one that blinks occasionally with activity. It’s locked up right now. The red LED is on, and i’m not seeing the green one blinking.

The Pi doesn’t use Standby mode therefore @sam_nazarko thought you have a Vero
This must be something with wake up from screen saver

If you turn on debug logging and once the stuck on dim happens again ssh in and type in

grab-logs -A

and then post that url here then that may give a better idea of what is happening.

debug logging is now on. now waiting for the lockup.

The lockup happened again today when i got home. I tried to do the grab-logs -A right away. I logged in successfully to the shell, but as soon as i ran that command, it returned nothing. I waited a good 5 minutes. I also noticed that the debug mode status banner at the top of the screen wasn’t changing at all. So i had to force reboot it by pulling power. I did the grab logs thing as soon as it came back up and here’s the link: https://paste.osmc.tv/wekovolite. Hopefully there’s something useful there.

This is a bit of a stab in the dark but I wonder if you swap out the hostname in your advancedsettings.xml for an ip address if that would make a difference. If it is just Kodi locking up then you might try instead of rebooting just run

sudo systemctl stop mediacenter

and once the command prompt comes back run

grab-logs -A

that server address is dynamic, So i’d have to keep up with it in the advancedsettings.xml file any time it changes. It’s always worked fine like this though and I’ve been using OSMC since it first came out. And it does connect to the DB and populate the videos and such like it’s supposed to. not sure why we think that might be the cause of the lockup.

Next time it locks up, i’ll try to stop kodi and pull the logs. Are the logs volatile? Do we lose what we’re looking for when I hard boot it?

The last thing showing in your kodi.old.log is it receiving a couple button presses from the OS but Kodi did not translate those into actions so I assume that is because Kodi was hung already at this point. I wonder if this is because it had lost it’s connection to the MySQL database at some point between when you were using it last. Switching over to using an ip address is just a quick and easy troubleshooting step, not a recommendation for a permanent change.

The Kodi.old.log shows the kodi.log from the previous boot but the system logs are volatile.

I’m not arguing the method or anything. Just trying to understand the methodology. I can try that change tonight.
Those last few button presses were probably me or my kids attempting to use the system. That’s how we discover it’s locked. At that point the display is already dimmed, and I hear the clicks of the button presses, but nothing happens. Is that normal for kodi to take no action on a button press if the DB connection is broken? I would have assumed that it would still do local operations like menu navigation. nonetheless, I’ll try to kill kodi and get the logs before rebooting. and if that fails, I’ll change that hostname to an IP.

I’d strongly suggest that you change the MySQL server to have a static IP address. It’s a really bad idea to have a server changing its IP randomly.

It just occurred to me, this is the only OSMC instance i’m seeing with this problem. I haven’t run into this issue on my other two boxes. That being said, this one gets used daily by the kids. The other two don’t get used as often. They’re all running on the same generation of Pi hardware. and all using basically the same settings in the advancedsettings.xml. I don’t think I have any more Pi 2s laying around, but I probably have a 3. Can I just pull the card from this one and swap it into a 3 and expect it to work? That test would rule out hardware.

It depends. From my personal experience it seems that if the MySQL db drops and comes back when the system has done nothing, then there is generally not an issue. You can often times do some browsing with the network dropped as long as it is only using cached info but once it actually sends an SQL query and the db doesn’t respond then Kodi hangs and will not recover from it. In other words, if i’m not actively using Kodi I can reboot the machine hosting my db, or any of the networking equipment that connects them, but longer periods of time can be problematic. I can see that there is some process that the skin helper service is running every half hour on your machine. I don’t know exactly what it is doing but it may be something that either requires access to the db, or forces access to it after its done.

I’ve had debug logging on ever since june 24th and it has only locked up that one time. I finally turned it off yesterday since that counter on screen was getting annoying and like clockwork it was locked up again when I went to turn it on today. It seems that the debug logging is doing something to keep it from locking up.
I was able to run the command to stop mediacenter from an SSH console. But now it’s sitting forever after issuing the grab logs command without returning anything to the console. Finally gave up waiting after 10 minutes and just power cycled it.

You can turn on debug logging without the overlay by doing with an advancedsettings.xml file instead of in the GUI.

<advancedsettings>
    <loglevel hide="true">1</loglevel>
</advancedsettings>

You will want to remove that once your done troubleshooting. As to the trouble with uploading the logs I would guess they are probably too large. With debug logging enabled you would probably need to reboot periodically to keep the size down.

To answer an earlier question you should be able to use a SD from a RPi 2 in a RPi 3 without issue.