Frequent random muting, then freezing

Thread Summary

(My original top post can be found further below. This is a summary of what we’ve collated so far.)

Bug description
At random times during playback, the sound will cut out and a few seconds later, OSMC will appear completely frozen up. In some cases the system is eventually able to recover, but CEC (remote control) is lost. Rebooting is usually the only recourse.

Known facts

(This space will be updated, as we learn more.)


(Original post)

This is an update (continuation?) of a previous thread, which was closed due to insufficient logging and data in people’s bug reports: Frequent random freezing

(Log file link: http://paste.osmc.io/aqacowutuv.vhdl)

The problem
At a random point during movie playback the audio will suddenly fail, and ~3 seconds later the whole system freezes up. Cycling the power appears to be the only way to ‘recover’.

I have only experienced this bug when playing movie files, but that is hardly conclusive, as movie playback is the only way I use OSMC on my RPi. I have not noticed any pattern that would indicate that the bug could be associated with any particular media files in my library.

How to reproduce
The random nature of the issue makes it hard to reproduce. Some days I have no issues, whereas other days the system will freeze several times during a movie.

I just logged this bug while viewing Spielberg’s ‘The Adventures of Tintin’ in 720p/mkv-h264/dca-5.1. In this instance the system froze during the movie’s opening credits (but an earlier attempt at catching the bug had me sitting through the entire movie without incident; a few days prior I watched the movie and got the bug 4+ times!). At this point I let the system sit for 10 minutes, just in case it was still offloading log data to the SD card. I then attempted to establish an ssh connection, but never received a response. (Update: This seems to have been a user error, though.) Pinging the RPi did work, though. I then rebooted the RPi by cycling the power, ssh’ed in and retrieved a full log of the crash via the command line: grab-logs --all --copy

The bug is therefore represented by the ‘Kodi Old Log’ entry in the log file.

Edit: This is entirely anecdotal, but it appears to me that the bug is much more likely to manifest itself when I do multiple successive skips during playback. This alone is not always enough to provoce freezing, and for this log entry I just left the system running on its own.

My setup
I’m on a RPi 2.0/B (rev. 0000e) running ‘OSMC October 2015 2015.10-1’. The system was previously clocked using the default OSMC settings, but I am currently using the default RPi settings: arm=700, sdram=400, core=250, initial_turbo=0, over_voltage=0, over_voltage_sdram=0, force_turbo=0. Even though this is considered underclocking compared to OSMC’s default values, the bug still occurs.

I’m usually running the Eminence skin, but the current log is using the standard OSMC skin.

Peripherals:

  • Logitech keyboard via USB Bluetooth dongle.
  • 4 GB SanDisk Ultra SDHC card.
  • Sony Bravia KDL-32EX501 TV connected via HDMI.
  • Ethernet connection to a router running DD-WRT v24-sp2 (05/23/14), which also serves a NAS that holds all movie files; OSMC connects to the NAS using SAMBA.
  • Power supply is a 1200 mA HNP06-050.

When did this issue begin?
Several users in this thread - Frequent random freezing - #41 by sam_nazarko - attested that the issue began somtime during September/October. I did not log when this bug began for me, but it sounds about right. Several users also reported that reverting to an August build alleviated the issue.

While trying to get a clean log of this bug, I noticed that the log files tend to terminate with the following line: “DEBUG: script.module.osmcsetting.updates : - blurp 18 - VideoFullScreen.xml”

One time, I also took a snapshot of the OSMC debug overlay immediately after the bug had frozen the system: “LOG: /home/osmc/.kodi/temp/kodi.log; MEM: 259700/362164 KB - FPS: 6.2 fps; CPU: CPU0: 54% (CPU-KODI 46.67%)” (I’d expect the fps value to be higher by an order of magnitude, but I don’t know if that is relevant here.)

6 Likes

Hi,

It’d be great if you could identify when this became a problem. We release a monthly update, and you can quickly identify this in the bottom left corner of My OSMC. We host old images at Download - OSMC.

When you find a ‘good’ version, do let me know, and I’ll walk you through upgrading in a partial way that allows us to identify the specific problem.

This will benefit other users, so your cooperation is very much appreciated

Cheers

Sam

Hi Sam,

Sounds good, although I have a few questions before I downgrade:

  1. Your message indicates that you want me to downgrade to a purportedly bug-free version - the ‘2015.07-1’ disk image seems a good candidate - and then do partial upgrades until the bug appears. However, since the bug occurs rather randomly, wouldn’t it perhaps be better to do positive identification by definitively confirming that the bug is present in, say, the ‘2015.08-1’ disk image and then work my way backwards towards the July release until I no longer seem to experience the bug?
  2. I have never downgraded before. Is there any way to (a) backup* and (b) re-apply my current settings to a vanilla release? I’m asking because the prospect of running a semi-disabled system looking for bugs for an indeterminate length of time obviously isn’t super appealing. :confused:

*) I’m using Win7/x64

All we need is confirmation of the last good build / first bad build. Feel free to find that point whichever way seems easier to you.

Personally I’d suggest you backup the whole sdcard (e.g. with win32diskimager) before you start. Then if anything gets messed up you can restore the sdcard exactly as it was.

I have the same random freeze during movie playback. System has to be power cycled for recovery.
I can back up the SD Card, but How do I roll back?

And this is happening on all 3 of my Pi.
1 B version.
2 B rev 2 versions

Same issue in my rpi 1 model BB with mkv files.

I’d recommend that you download an older version of OSMC. If we can find the most recent version where things worked OK, this will help, and then we can move on from there, although I’m not certain that this will be unanimous.

Cheers

Sam

(I need to use OSMC for an upcoming video night, and enticed by reports from another user - Infrequent Random Crashes When Playing Video - #17 by megardi - I first tried to disable ‘omxplayer acceleration’ before going full rollback.)

Setup: as in the top post, except that ‘omxplayer acceleration’ was disabled, the RPi rebooted by power cycling, and left to its own devices for for ~5 hours. When I checked in on it, it had frozen up, as described above, even though the system had not been touched at all. :no_mouth:

Following a hard reboot, ssh and ‘grab-logs --all --copy’, the relevant log entry is ‘Kodi Old Log’: http://paste.osmc.io/ugelagewad.vhdl

Anyway, commencing with downgrade to the release ‘OSMC_TGT_rbp1_20150628.img’ in the hope that video night goes well and without hiccups.

Update: Upon trying to write the Agust disk image to the SD card, Win32DiskImager failed with the message that my 4GB card was only ~240 MB. I tried various ways of formatting it, but failed to re-gain the full 4 GB and started to suspect I had a Chinese knock-off. However, this guide worked in properly reformatting the card: http://www.instructables.com/id/How-to-format-your-SD-card-back-to-the-original-si/step2/ADVANCED-PROCESS-DiskPart/. I’ve recording my steps here in case others run into problems while rolling back:

  • command line: diskpart
  • list disk; select disk [#number-of-my-SD-card]
  • clean; (pop card out, then re-insert); list disk (to confirm proper size)
  • create partition primary; format quick; exit

I then wrote the disk image ‘OSMC_TGT_rbp1_20150628.img’ to the card and booted into OSMC.

Update 2: My SD card apparently got messed up while ‘clean’-ing it with diskpart. After the cleaning, I couldn’t ‘list disk’ or even restart diskpart anymore, not even after rebooting the PC. Windows couldn’t format the card, but the SD Association’s formatting tool was able to quick format the card (SD Memory Card Formatter | SD Association), after which I could write the disk image as usual.

  • ‘OSMC_TGT_rbp1_20150628.img’ does not appear to be affected by this bug.
  • ‘OSMC_TGT_rbp1_20150805.img’ does not appear to be affected by this bug.
  • ‘OSMC_TGT_rbp1_20150830.img’ does not appear to be affected by this bug.
    • Kernel 4.2.3-3-osmc is definitely affected by this bug.
  • ’OSMC_TGT_rbp1_20151027.img’ is definitely affected by this bug.

(I will update this post as I learn more.)

(While going through the post-installation steps of setting up ‘OSMC_TGT_rbp1_20151027.img’ I noticed that there was no internet connection - the network settings screen said: ‘Status: eth0 (not connected)’. This is another issue that I have been fighting lately, but remarkably, I have not had any connectivity issues this past week while testing out the prior releases. Going back and forth between applying manual and DHCP settings usually restores the connection, but since this might be a router issue, I’m not going to escalate this until I have verified whether this is in fact specific to this particular release.)

Update (note to self): I noticed that setting my movie location to ‘IP.NUMBER:/Public/Film/’ resulted in the scraper only picking up movies in separate sub-folders. Removing the last slash (i.e. ‘IP.NUMBER:/Public/Film’) magically fixed everything. I haven’t noticed if this unexpected behavior was present in the earlier releases; I should check to see if this is another problem with this release. Edit: It’s not an issue on ‘OSMC_TGT_rbp1_20150830.img’.

I just experienced the bug on ‘OSMC_TGT_rbp1_20151027.img’ (OSMC October 2015 2015.10-1): Muting, followed by complete lockup a few seconds later. This confirms that the October release is the first version to exhibit this bug.

Behavior
This time I left the system running and tried to ssh into the RPi. Contrary to previous experience, I was able to connect (I suspect I must have mistaken the DHCP’ed IP on previous occasion) and retrieve the log. Remarkably, as I did this the OSMC came to and resumed playback with audio. However, CEC was lost, although OSMC could still be controlled via the Kore Remote app for Android; this completely mirrors this bug report: CEC Issue

Logs
Here are the logs. (I apologize for their lengths, but I was not intending on creating a concise log, but rather identify the first release, where the bug occurred.)

Please note this excerpt from kodi.log:


23:35:15 16890.058594 T:2579866656 ERROR: CDVDMsgGeneralSynchronize - timeout
23:35:45 16920.076172 T:2571478048 NOTICE: Closing stream player 3
23:35:45 16920.076172 T:2571478048 NOTICE: Opening stream: 6 source: 256
00:32:48 20343.099609 T:2740511776 NOTICE: ES: Incoming connection from Kore Remote
00:32:56 20351.052734 T:2808083488 NOTICE: Thread JobWorker start, auto delete: true
00:32:57 20351.816406 T:2903802912 WARNING: COMXImageFile::GetCodingType progressive images not supported by decoder

The bug occurred around ~00:20, where I promptly got up and connected via ssh, which seemed to defrost the system. I then played around a bit with my remote, before I finally connected with Kore Remote at 00:32:48. I don’t know if the absence of log entries between 23:35:45 and 00:32:48 is considered normal when auto-updating is disabled, but I was definitely taken aback by it?!

What next?
I’m ready to downgrade to ‘OSMC_TGT_rbp1_20150830.img’ and begin partial upgrades, at the discretion of a developer.

I urge others that experience this bug to join in so we may run tests in parallel.

Update I: I realize that the ‘gap’ in the log might happen because I didn’t enable debug logging?

Update II: Having ‘revived’ OSMC by ssh, as described, I left it playing. When I returned quite some time later, I found that it had frozen up again. I had left the Info screen on, so I was able to tell from the on-screen time that it had been frozen for approx. 15 minutes. Moreover, for some reason the movie’s progress bar was full. I then went to my PC and closed the ssh connection. This promptly un-froze OSMC and reset the on-screen timer (but not the progress bar), but weirdly I was now fast-forwarded through the rest of the movie (no audio). CEC still didn’t work, but I was able to pause the movie with Kore Remote. Pressing play merely resumed fast-forward playback, though. Having finisehd the movie the system returned to the main menu as normal (with sound restored). I have screenshots and logs of the event, but unfortunately they weren’t captured with ‘debug logging’ activated.

I also have this problem.
I used to have osmc on a raspberry pi 1 and when watching movies and streaming, after 1 hour, sometimes after 30 minutes, it crashed and stopped responding, had to disconnect power, tried underclocking but it didnt help.
But it seems to be more common if there is no ventilation
Now i have a pi 2, and although the freeze is now not so common, it still happens sometimes
It would be useful if we could solve this.
Thanks

I have a lengthy(!) log detailing the apparent freeze/lock-up of OSMC, accompanied by long periods of no logging with intermittent activity. Eventually the system appeared to have recovered, albeit with the volume automagically muted.

I created an interesting log entry vs. time stamp graph that clearly shows periods of apparent inactivity:

I actually tried to connect via ssh to ‘jump start’ OSMC (see my previous post), but I was unable to connect this time; it seems ssh it hit-and-miss while this bug is in effect.

For anyone looking to tag along here, this is what Sam Nazarko instructed me to do:

If 0830 is working fine, start by upgrading the kernel

sudo apt-get install rbp1-kernel-osmc
If this doesn’t hang, update Kodi:

sudo apt-get install rbp1-mediacenter-osmc
If this doesn’t hang, update fimware:

sudo apt-get install rbp-bootloader-osmc

I’m now going to go ahead and install ‘OSMC_TGT_rbp1_20150830.img’ and then upgrade the kernel.

Update: Seems you need to do a ‘sudo apt-get update’ first, if you want to do a partial upgrade of OSMC out-of-the-box.

Just a big warning these are the commands for a Raspbery Pi 1, don’t run them on other platforms.

For a Pi 2, change to ‘rbp2’. bootloader package is the same

Sam

Update: I just found that the 4.2.3-3-osmc kernel in itself was sufficient to elicit the bug. Disregard the report here.


The ‘kill-audio-then-freeze’ bug appeared today, 46 seconds into Finding Nemo: http://paste.osmc.io/ibizejecap.coffee

I am currently running ‘OSMC_TGT_rbp1_20150830.img’ with the kernel upgraded to 4.2.3-3-osmc and Kodi upgraded to 15.2 (comp. Oct 21st, 2015). It appears that the Kodi upgrade (not the kernel) is responsible for the bug.

Is there any way to do a partial upgrade of Kodi itself, or do I start on component-specific logging?

It’s been a month since I have this issue too. I first thought it was the SD card, the power supply, etc.

Today I monitored kodi and systemd logs by watching TV series and movies while connected by SSH and I noticed that while Kodi was frozen, my ssh sessions where still responding.

By making a new ssh connection or by closing one that was already up, Kodi would unfreeze and catch up some buffer.

After each « unfreeze » I see those lines in journalctl :

Nov 28 22:29:50 osmc systemd[1]: systemd-logind.service watchdog timeout (limit 1min)!
Nov 28 22:29:50 osmc systemd[1]: Unit systemd-logind.service entered failed state.

Maybe it’s a lead…

Still the same with today’s upgrade.

Here are the logs : http://paste.osmc.io/irobegawoy

Are you streaming via NFS?

I’d like to see systemctl status systemd-logind -l when this happens again.

Also would like to see;

  • /var/lib/dbus/machine-id contents
  • systemctl status connman -l
  • May also help to set storage=persistent in /etc/systemd/journald.conf

Sam