The compressed backup is created in that temp folder and then moved to whatever location is set in My OSMC. I don’t think there is any kind of cleanup check done at present. I remembered that being a cause of low disk space at times, and causing some future backups to fail even if there was enough space, and I have a bit of a fuzzy memory of a time or two where it caused some unrelated issues, but I didn’t remember it being slow playback start. Perhaps @anxdpanic can look into adding something to our add-on.
Indeed. My Backup folder does have recent backup files in it, 2 as configured.
Now that this particular mystery is solved, I have another one I would like some help on. Once I have enough empirical data, I’ll bring it up in a new thread, as I believe this problem is unrelated to any of the above.
Thanks again.
What is the issue? You are correct in that we prefer to keep topics separate and all that but if it is a known issue perhaps you can save some time and effort just stating what the other problem is.
I’m still trying to pin down the exact behavior. But since the OSMC upgrade (for 11/20 to 7/23), my Kodi instance seems to become non-responsive when left idle for a certain – as yet undetermined, at least a couple of hours and certainly overnight – period of time.
By unresponsive, I mean Blank screen, and non responsive to remote signals, or web controller. The really strange bit is that if I stop and restart mediacenter at the command line, it starts up with Kodi in the exact same blank and non-responsive state. Only a reboot seems to get things back to normal.
Also, I’ve determined that this doesn’t happen if I leave things with a video paused during playback. But outside of playback, this seems to happen fairly reliably, independently of where I left off navigating.
I use Blank as a screensaver, so the next thing I’m about to test is whether this still happens even if I use a more active screensaver.
When you think it is locked up maybe try opening a ssh session and do a
tail -f ~/.kodi/temp/kodi.log
and then in a separate instance ssh in and send it commands to determine if it is actually locked up or if there is a display issue…
kodi-send -a toggledebug
kodi-send -a "ActivateWindow(videos)"
kodi-send -a "ActivateWindow(home)"
The above should show in the first window messages about it switching views if it hasn’t actually hung. If that works then you might see if the following brings the screen up…
Kodi-send -a CECActivateSource
If it is non-responsive I would temporarily switch to Kodi default userdata that you don’t bother configuring at all and just let it sit. If it still displays the same behavior then that will help narrow down where to look.
It remains non-responsive, but I do have some additional data.
First off, you were right to suggest that I bring up the issue in this thread, because I think the problem is related to the same partial backup file oddness.
The reason I haven’t updated this thread in a while is that the Blank outages mysteriously stopped happening after I posted about them here. I couldn’t think of any major configuration changes I had made, aside of course from moving aside those large backup files in .kodi/temp that had been causing the delayed playback start.
So I decided to move them back into .kodi/temp, and guess what? Kodi became non-responsive again in due time. So it looks like those aborted backup files are involved in this mischief too.
As I mentioned above, the kodi-send’s from the other shell didn’t do anything at all. It’s too late in the evening (i.e. I’m too drunk) to experiment with the blank userdata, so I’ll try that tomorrow morning. But I’ll mention for now that the log tail has brought up a couple of new lines while I was typing this post:
2023-08-26 23:12:58.121 T:9780 info : ES: Client from ::ffff:127.0.0.1 timed out
2023-08-26 23:14:59.742 T:9780 info : ES: Client from ::ffff:127.0.0.1 timed out
2023-08-26 23:28:21.132 T:9780 info : ES: Client from ::ffff:127.0.0.1 timed out
I assume they were triggered by one or other of the kodi-send commands, since no message appeared during the 13 minutes I didn’t issue any kodi-send’s. But it’s hard to say which kodi-send command is responsible, since the message doesn’t appear in the log file until whatever timeout is up.
Do you have backups scheduled in My OSMC? I’m not familiar with that particular message but it looks like something in Kodi’s event server api was having an issue, not something to do with any particular command that was coming in. I have sent many, many bad action id’s to Kodi via kodi-send and never once had it cause a problem. Basically if your command is correct then Kodi does what you told it to do. If you send a bad command then literally nothing happens and it doesn’t even get logged. Not that the commands I posted above are bad. There not, I tested them before posting.
First off, my apologies for my previous post. I should know better than to post while tipsy. And I need to do a do-over, as it contained both incorrect and misleading statements.
Let me try to make amends here:
I do. They’re scheduled to take place before the weekly check for Updates in My OSMC. And they seem to work as expected, although from those files left behind in temp, it appears that it failed to complete twice this calendar year.
But I need to correct myself here about what I previously wrote about the Freeze problem being related to the presence of those partial backup files in .kodi/temp. That is not the case. The Freeze occurs whether those partial backup files are in .kodi/temp or not. Sorry for that bad data point.
I can now get Kodi to Freeze at will by simply navigating home and waiting for my Black screensaver to kick in. Kodi becomes non-responsive within another minute or two. If I idle in other locations, it doesn’t seem to happen as quickly.
I may have to disagree there.
I am not saying there’s anything “bad” about the kodi-send commands. But there seems to be a direct cause-and-effect between my typing a kodi-send command in a shell and the appearance of that error message about 61 or 62 seconds later. Let me try to illustrate what I mean:
osmc@razpy: ~$ date ; kodi-send -a “ActivateWindow(videos)”
Sun 27 Aug 2023 11:24:48 AM EDT
Sending: {‘type’: ‘action’, ‘content’: ‘ActivateWindow(videos)’}
osmc@razpy: ~$
Over in the log file, this shows up 61 seconds later:
2023-08-27 11:25:49.818 T:3612 info : ES: Client from ::ffff:127.0.0.1 timed out
I wait a few minutes, and then in the same shell:
osmc@razpy: ~$ date ; kodi-send -a “ActivateWindow(home)”
Sun 27 Aug 2023 11:29:39 AM EDT
Sending: {‘type’: ‘action’, ‘content’: ‘ActivateWindow(home)’}
osmc@razpy: ~$
And over in kodi.log, 61 seconds later with no other intervening messages:
2023-08-27 11:30:40.638 T:3612 info : ES: Client from ::ffff:127.0.0.1 timed out
I can do this as often I like, and there is always a 61 or 62 second gap between one thing and the other.
I hope this clarifies my previous post.
I’ve learned a few other things since then, having tested with a real (i.e. not Black) Screensaver since. The Freeze still happens, but the kodi-sends DO have a positive effect in those circumstances. I don’t have time to get into details right now. But I’ll go into that when I post again.
Again, thanks for your interest and your help.
I understood that. Kodi has a network port that it listens in on for control commands and kodi-send is issuing those commands via the loopback address which is what your seeing in your logs. Kodi is seeing the command come in but the code that is suppose to actually do something with these commands seems to not be responding.
My point to this exercise was to determine if Kodi was locking up or if perhaps it something more along the lines of the TV doing something funky with CEC and the input was switching. It would appear that Kodi is indeed becoming unresponsive so that test still narrowed things down a bit.
I believe your instinct is correct that this is all CEC related.
When I decided to test with a Screensaver other than Black, I chose Aerial which I had used in the past. I left it running overnight and found the unit non-responsive in the morning frozen on a still image from one of the Aerial videos. I tried the kodi-run commands you had suggested. The first one caused some activity in the log file but didn’t make the unit any more responsive. The second one unwedged things and left me at a perfectly responsive home screen.
I didn’t save the log from that time, but I was able to reproduce the behavior later on to capture the following. The commands were isssued when the device hung immediately upon trying to launch the screensaver. Again, the first command caused log activity without making the unit responsive. The second did the trick, with no real corresponding log file activity.
Commands:
osmc@razpy:~$ date ; kodi-send -a “ActivateWindow(videos)”
Sun 27 Aug 2023 06:17:09 PM EDT
Sending: {‘type’: ‘action’, ‘content’: ‘ActivateWindow(videos)’}
osmc@razpy:~$ date ; kodi-send -a “ActivateWindow(home)”
Sun 27 Aug 2023 06:17:55 PM EDT
Sending: {‘type’: ‘action’, ‘content’: ‘ActivateWindow(home)’}
osmc@razpy:~$
Corresponding log:
https://paste.osmc.tv/raw/dicogoxeqa
I hope this information is useful, but I think I’ve found a workaround that suits my needs, which is to disable CEC entirely. To make a long story short, Aerial exhibited an annoying behavior it didn’t have in the past for me. It kept forcing the TV input to switch back to Kodi whenever the next Aerial video started playing. When I couldn’t find a combination of CEC settings to prevent this antisocial behavior, I decided to turn off CEC entirely. And I promptly discovered that the unit stopped freezing or hanging as a result, regardless of which screensaver I use.
That’s good enough for me, as the only real use I had for CEC was to have the TV input automatically switch to the unit whenever it rebooted. I can live without that.
In any case, I’m now ready to move on to my next post-upgrade issue, which is that my unit is now struggling to decode video that didn’t trouble it before. I will start a new thread for that issue in the next couple of days.
Thanks again.
When a screensaver is on the first keypress/action id turns off the screensaver so it not doing what you told it to do the first time you told it is the expected behavior.
I think it’s the switch source on startup setting. That setting controls more that just initial boot. That screensaver is playing videos so this is also what I would expect to happen. You might instead though play with the DPMS options in the Aerial screensavers settings. Although your TV likely doesn’t support DPMS that setting has the ability to pause or stop the video playing.
You’re right. I disabled that setting, and the antisocial behavior from Aerial stopped. Even better, my TV still switches to the Kodi input upon initial boot. So that’s a win-win for me.
Elsewhere, I have another update on my hang problem:
I was incorrect that disabling CEC got rid of it. Instead, I think it stopped happening when I would leave the unit idle while navigated to a media folder, which is how I usually leave it. However, last night, I left the UI navigated to the home screen and found the unit hung again this morning.
After further testing, I feel it’s safe enough to say that it seems to hang when left idling at the home screen, but not elsewhere in the UI. (Obviously, I realize that my track record for making such pronouncements is… not good.)
Meanwhile, I have something that may or may not be a clue. When I found Kodi hanging this morning, the last set messages in the log file was the following:
2023-08-29 02:08:41.832 T:2712 error : GetDirectory - Error getting VideoLibrary
2023-08-29 02:08:41.833 T:2712 error : CGUIMediaWindow::GetDirectory(VideoLibrary) failed
2023-08-29 02:08:41.879 T:2712 error : ExecuteAsync - Not executing non-existing script script.tv.show.next.aired
I thought this might have been useful, because my skin’s home screen normally cycles through my library to show off assorted cover art. But I’ve since gotten the unit to hang at the home screen without the re-appearance of those messages. Still, I’m offering them up just in case, if only because similar error statements previously led to the indictment of those leftover backup files in the case of the delayed playback.
I’d power down and then pull your SD card and clean it with isopropyl alcohol or electronic contact cleaner. If you don’t happen to have either of those you can gently go over the contact pads with a soft pencil eraser. If that makes no difference try another PSU or SD card. Your database shouldn’t be going MIA.