[david1976aus]

Hi All.

I was wondering if anyone had any similar experiences on OpenElec 5.0 on RPi where Kodi will crash and require a reboot (either via SSH or remove power) when a TV Show or Movie has been paused for extended periods of time.

[wrxtasy]

Check:
- Power Supply
- Thickness of USB power cord
- Age of SD card
- System Info for any overheating issues
- Dodgy add-ons that are crashing Kodi....

[Koile]

I have the exact same issue as the OP - it only happens when I pause for more than 2 or 3 minutes

My setup has been running fine for over a year now, this problem just showed up when I updated from OpenELEC 4.21 to OpenELEC 5.0, so everything you asked to check is OK

[popcornmix]

Are you using the cache? (e.g. using internet streams or buffermode?)
Have you changed cachemembuffersize?

It could be too much memory (or sdcard space) is allocated to the cache, and pausing allows it to consume all of memory/sdcard.

[Koile]

I'm just streaming from my NAS in the same LAN
The memory of the SD-card is also fine - several GB of free space left.

I have not changed anything regarding the cachemembuffersize

[popcornmix]

A debug log (wiki) file may have some clues.

[Milhouse]

Or the kodi_crashlog from a a crash-log enabled OpenELEC build.

[brimur]

I have this issue also. I have seen it since the first Kodi alpha and just assumed it was a known issue. I have only ever used Openelec so it could be that too. Kodi freezes so the only fix for me is to ssh in to the box and either kill the process our reboot.

[Milhouse]

And nobody has a debug log or crash log? No log, no problem...

[afremont]

And nobody has a debug log or crash log? No log, no problem...

I'm not sure if this is related to the other people's problems, but it kinda smells like it could be. I'll send you a log with debugs if you want, but I'll have to wait til tonight to leave it paused for a long time. Let me know what specific detailed debug info you need. The Pi didn't fully crash, but it got pretty slow in the user interface while a TV recording was playing. This was on a nightly so I didn't think much of it. I posted the big log to the OpenELEC thread right here:
http://forum.kodi.tv/showthread.php?tid=211501&page=71 Post 1057

I originally posted 1057 due to all those weird messages about timing out waiting for a buffer and the avcodec_decode_subtitle messages. maybe it's related to the crashes that are being mentioned. The latest nightly (312) doesn't seem to be generating near as many messages, but the user interface is kind of spongy still when a recording is playing.

When the wife left it paused for a long time (about an hour, maybe two while making supper), it got really sluggish. The recording was doing like 2 or 3 frames per second and no audio. Stopping and restarting the recording got it playing decently again, but the whole "machine" was still pretty sluggish while the recording was playing. At that point, she made me switch back to the 5.0.5 release so I didn't get to do any real investigation. Even after a fresh boot, skipping ahead and back in a recording (while it's playing, not when it's paused) is sluggish compared to 5.0.5. There's a slight, but noticeable delay before the video gets going again (as compared to the snappiness of 5.0.5. Every time you skip ahead or back (while it's playing), a slew of those messages comes out, even with build 312.

Here are a couple of standard logs, starting from a fresh boot and resuming the same recording each time.

In 5.0.5 I get an ERROR about not being able to init the overlay code:
http://sprunge.us/VJBS

In the nightly, I don't get that ERROR, but instead I start getting wads of those other messages:
http://sprunge.us/hOKJ

In each log, I fresh booted and navigated to the same recording, resumed it. On the 5.0.5 log, I pastebined it before ending the video I did skips in the 5.0.5 version and got no log messages. In the nightly I didn't have to do any skips, they started coming out as soon as I resumed the recording. After that, they only come out when doing skips and then they stop once the video gets going again.

In both cases, I don't have subtitles enabled during playback.

I never got any crash logs, just sluggishness that seems like it is eventually going to lead to a crash or freeze. I'll try leaving something paused tonight, all night and see if I wake up to an unresponsive machine. Then I'll ssh in (assuming I can) and check CPU usage (if kodi is still in execution) and VSZ to see if it looks like a leak is occurring.

I know I'm long winded, but I want to try and include as much info as I have. This is not a complaint, just trying to be helpful and provide you with something that you can use. I appreciate your work greatly. Hopefully I can give something besides "criticism" at some point. Let me know if you need/want anything else from me.

[Milhouse]

Let me know what specific detailed debug info you need.

It's not obvious what is causing this problem, which seems to be very rare, so it's not possible to say what specific debug information is required. If Kodi is crashing then a crash log will be absolutely vital and should exist if users are using a crash log enabled build. Since your Pi is not crashing it's possible you're experiencing a different issue, but thanks for the logs - always useful!

[afremont]

One difference I see is that I was watching recorded TV. I haven't tried pausing live tv or a "movie" for an extended period. I'll leave live tv paused for a while and see what happens. If I get a crash, it should generate a crash log right? I notice that playing live TV it doesn't open the individual streams, or at least there aren't those type of messages in the log.

Digging around the net, it looks like .wtv files are kind of fishy anyway when it comes to subtitles. That warning about the unknown codec for stream 0.2, is that anything to worry about?

I restarted the Pi, put on a live tv program and then paused it. I'm going to work on some other things I got going on, and I'll just let it sit and see what happens. I have a tail -f running on the kodi log and a top running in another ssh session. A third session is running a watch -n 1 date so if it locks I'll know what time it occurred and I'll have the regular log trapped in the scrollback buffer of putty. The top command shell will have a pic of what was going on when it froze. Maybe that will be of some help. So far it's been going for about 25 minutes and nothing seems amiss in the ssh sessions. Maybe it doesn't come unglued until it's actually unpaused. If need be, I'll let it sit all night and then unpause in the morning and see what happens.

I really wish I knew enough (actually anything) about the source to start looking for something. Do you keep your nightly source trees on github? If so, is it open to the public? Thanks for reading. I'm a fish out of water right now, but I'll adapt. You'll see.

[Milhouse]

If I get a crash, it should generate a crash log right?

If you're using OpenELEC this needs to be a build based on master, so either a nightly or test build but not an official release build. The crashlog will be generated automatically (/storage/.kodi/temp/kodi_crashlog.log).

Digging around the net, it looks like .wtv files are kind of fishy anyway when it comes to subtitles. That warning about the unknown codec for stream 0.2, is that anything to worry about?

Not sure.

I restarted the Pi, put on a live tv program and then paused it. I'm going to work on some other things I got going on, and I'll just let it sit and see what happens. I have a tail -f running on the kodi log and a top running in another ssh session. A third session is running a watch -n 1 date so if it locks I'll know what time it occurred and I'll have the regular log trapped in the scrollback buffer of putty. The top command shell will have a pic of what was going on when it froze. Maybe that will be of some help. So far it's been going for about 25 minutes and nothing seems amiss in the ssh sessions. Maybe it doesn't come unglued until it's actually unpaused. If need be, I'll let it sit all night and then unpause in the morning and see what happens.

I'm also leaving a tvshow paused, and will come back to it in a few hours...

[Claudio.Sjo]

Hi all,
I'm investigating other problems related to the file caching in Kodi, and I see that they can be in a way related.
As Milhouse knows, I'm working on an audio player based on Kodi, with a CDROM for Ripping CDs.
The first problem I found is related to the interface between Filecache and CDDARead, as the second was not aligned with the Filecache API.
After fixing the problem, I actually found out something much difficult to investigate, but it sounds to be similar to the one investigated here.

What happens in my case is the following (an heavy skin is needed, it doesn't happen with Confluence)
during the ripping phase of an Audio CD, that exploits FileCache mechanism, the whole Audio track is read in cache
and then the user application reads from the cache.
It happens that the user application reads the whole cache, but this doesn't trigger reading from the CD,
I logged the user reading activity, and the user gets zero data, still the Filecache algorithms doesn't trigger
the file reading, so that the activity is silently dropped.

I gave me an explanation by reading Cachestrategy, and I suppose it works in this way: when caching starts
two parameters are calculated, one is the user requested bandwidth and the other is the source provided bandwidth,
then during the reading, the buffering activity is executed in order to cope with the cache size and the needed bandwidth.

If for some reasons (i.e. press "pause") the user bandwidth is drastically changed, then Kodi fails in adjusting the reading ratio,
and such behavior would explain both my problem as well as the problem faced here.
In my case, the use of an heavy skin makes the bandwidth calculation wrong, and Kodi would assume a very little user bandwidth
and this would make the cache empty.

Please people who knows about FileCache strategy comment.

[Milhouse]

8 hours with a video on pause and no crash, it resumed flawlessly...