Sonarr crashing (coredump / SIGSEGV) in

Sonarr version (exact version): (Home:Junknot OBS repository)
Mono version (if Sonarr is not running on Windows):
OS: OpenSuse Tumbleweed
Debug logs: (See below)
Description of issue:

Hi all, Sonarr has been crashing on me relatively constantly since upgrading to the latest version - initially this was happening on initial import of the library after upgrade, but I moved some files out of the way and managed to stop that, now its happening on downloading new releases.

I have recovered the stack trace from the journal:

        Native Crash Reporting
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
        Native stacktrace:
        0x55e480b77cd0 - /usr/bin/mono :
        0x55e480b78079 - /usr/bin/mono :
        0x55e480b26e71 - /usr/bin/mono :
        0x55e480b7189d - /usr/bin/mono :
        0x7ff21af68476 - /lib64/ :

at <unknown> <0xffffffff>
at NzbDrone.Core.MediaFiles.MediaInfo.MediaInfo:MediaInfo_Open_Buffer_Continue <0x000b8>
at NzbDrone.Core.MediaFiles.MediaInfo.MediaInfo:Open <0x000ff>
at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader:GetMediaInfo <0x00293>
at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader:GetRunTime <0x0004f>
at NzbDrone.Core.MediaFiles.EpisodeImport.DetectSample:IsSample <0x0016d>
at <>c__DisplayClass14_0:<GetNonSampleVideoFileCount>b__0 <0x00050>
at System.Linq.Enumerable:Count <0x000c8>
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetNonSampleVideoFileCount <0x001af>
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetImportDecisions <0x001c3>
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetImportDecisions <0x0005f>
at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService:ProcessFolder <0x0044c>
at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService:ProcessPath <0x000ef>
at NzbDrone.Core.Download.CompletedDownloadService:Import <0x0010e>
at NzbDrone.Core.Download.DownloadProcessingService:Execute <0x002b0>
at NzbDrone.Core.Messaging.Commands.CommandExecutor:ExecuteCommand <0x00210>
at System.Object:CallSite.Target <0x00122>
at System.Dynamic.UpdateDelegates:UpdateAndExecuteVoid3 <0x001bc>
at System.Object:CallSite.Target <0x00191>
at NzbDrone.Core.Messaging.Commands.CommandExecutor:ExecuteCommands <0x0032f>
at System.Threading.ThreadHelper:ThreadStart_Context <0x000aa>
at System.Threading.ExecutionContext:RunInternal <0x00191>
at System.Threading.ExecutionContext:Run <0x00042>
at System.Threading.ExecutionContext:Run <0x00063>
at System.Threading.ThreadHelper:ThreadStart <0x00042>
at System.Object:runtime_invoke_void__this__ <0x00091>

The crashed thread is the one.

The trace logs contain literally nothing unusual, however the last entry in the log is usually something along the form of :

2023-04-14 02:26:20.3|Debug|ImportDecisionMaker|Analyzing 1/1 files.
2023-04-14 02:26:20.3|Debug|Parser|Parsing string 'Station.19.S06E14.720p.HDTV.x264-SYNCOPY'
2023-04-14 02:26:20.3|Trace|Parser|^(?<title>.+?)(?:(?:[-_\W](?<![()\[!]))+S?(?<season>(?<!\d+)(?:\d{1,2})(?!\d+))(?:[ex]|\W[ex]){1,2}(?<episode>\d{2,3}(?!\d+))(?:(?:\-|[ex]|\W[ex]|_){1,2}(?<episode>\d{2,3}(?!\d+)))*)\W?(?!\\)
2023-04-14 02:26:20.3|Debug|Parser|Episode Parsed. Station 19 - S06E14
2023-04-14 02:26:20.3|Debug|Parser|Language parsed: English
2023-04-14 02:26:20.3|Debug|QualityParser|Trying to parse quality for Station.19.S06E14.720p.HDTV.x264-SYNCOPY
2023-04-14 02:26:20.3|Debug|Parser|Quality parsed: HDTV-720p v1
2023-04-14 02:26:20.3|Debug|Parser|Release Group parsed: SYNCOPY
2023-04-14 02:26:20.3|Debug|VideoFileInfoReader|Getting media info from /home/(removed)/.sabnzbd/downloads/complete/Station.19.S06E14.720p.HDTV.x264-SYNCOPY/b8ef54b3cda8455bbb65814bb94a2e13.mkv

is it possible my is somehow incompatible? Its quite difficult to tell, as its not versioned on my system:

file /usr/lib64/
/usr/lib64/ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=61a5cf2fde04f271fbe2bd2e0473f98b11b2f2fd, stripped

Any help would be gratefully received. I can post full logs if necessary, but there is literally nothing in even the trace logs that shows anything wrong, they just … stop after “getting media info”

1 Like

Sounds like I have a similar problem with Sonarr crashing.

        Native stacktrace:
        0x4b8ac3 - /bin/mono : (null)
        0x4b8dcc - /bin/mono : (null)
        0x464c71 - /bin/mono : (null)
        0x4b193f - /bin/mono : (null)
        0x7fd19575fb8d - /lib64/ : _ZN6ZenLib12BitStream_LE3GetEm

Linux 3.10.0-1160.88.1.el7.x86_64

I’ll be following this thread with interest.

Hi - what version of libmediainfo do you have? My system upgraded to 23.03-1.1 from 22.12-1.2 on the 1st April, which is about when the crashes started for me, and the major version upgrade makes me extremely suspicious. I was going to attempt an upgrade to 3.10 to see if it fixes anything, but this now looks less likely.

Sorry to hijack your thread, just wanted to say thanks for the pointer. This was exactly my problem. Once I downgraded libmediainfo and mediainfo it is stable again.

Here’s what I did to tide me over until there’s a more permanent fix:

yum erase mediainfo libmediainfo
rpm -i libmediainfo-22.12-1.el7.src.rpm mediainfo-22.12-3.el7.src.rpm 
systemctl start sonarr

I’ve blacklisted these packages in my yum.conf until a fix is found.


1 Like

Ah, that’s actually really good news - I tried to downgrade my libmediainfo last night but discovered that OpenSuse Tumbleweed doesn’t keep old packages for … reasons, and thus could not.

That was the smoking gun I was looking for however, so will move this to a bug report on github, as I think we will get next to no attention here. I will post the link when created, any backup / extra data would be extremely useful :slight_smile:

I managed to source old rpms from and can confirm that downgrading mediainfo and libmediainfo fixes the crashes. I won’t attach the rpms here, but I have them stashed locally, if anyone needs, and they have gone from the above. Hopefully a fix will be relatively quickly incoming.

Hm. So, as per the bug tracker above, its a known problem with a bad release of mediainfo, which will crash on all mkvs (mediainfo and libmediainfo throwing segmentation fault on files · Issue #707 · MediaArea/MediaInfo · GitHub). They have a patched development release version available, but not a full release yet, unsure as to when this will happen.


Same here.

# ls -lh /usr/lib64/*
lrwxrwxrwx. 1 root root   24 Mar 31 19:00 /usr/lib64/ ->
-rwxr-xr-x. 1 root root 8.1M Mar 31 19:00 /usr/lib64/

edit: sorry, this was posted very late because I’m a noob.
I had the same issue. Reverting mediainfo and libmediainfo to <23.x let Sonarr v3 run again on my Fedora 38 build.
An alternative to the procedure above is to use dnf versionlock on the packages.
Other versions for Redhat-based RPMs: libmediainfo mediainfo

Someone said so on github but I’ll post it here because I confirmed it: Sonarr v4 beta isn’t affected. I was able to remove mediainfo and libmediainfo after upgrading. caveat emptor

I encountered this, and “fixed” it by upgrading to v4.
V4 uses ffprobe (part of ffmpeg tools) bundled with the release package.

W/r/t removing, other things may depend on the library and will also break.
Downgrading is a far better course of action.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.