App crashing when performing RefreshSeriesService

Help & Support
1

For the last week Sonarr has been crashing, soon after start-up, when Refreshing the Series.
It always seems to crash when it is interrogating the second series in my library.

Thinking it was a corrupt media file, I removed the original offending tv-pgm directory from both the physical directory and the series database. But I receive the same error message when it gets to the (new) second tv pgm: 7 Days

[Info] DiskScanService: Completed scanning disk for 24
[Info] RefreshSeriesService: Updating Info for 7 Days (2009)
wrong maximal instruction length of instruction tls_get (expected 8, got 20)

  • Assertion: should not be reached at mini-arm.c:5591

Stacktrace:

at <0xffffffff>
at (wrapper managed-to-native) object.__icall_wrapper_mono_delegate_to_ftnptr (object) <IL 0x00021, 0xffffffff>
at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipLoadImageFromDelegate_linux (System.Drawing.GDIPlus/StreamGetHeaderDelegate,System.Drawing.GDIPlus/StreamGetBytesDelegate,System.Drawing.GDIPlus/StreamPutBytesDelegate,System.Drawing.GDIPlus/StreamSeekDelegate,System.Drawing.GDIPlus/StreamCloseDelegate,System.Drawing.GDIPlus/StreamSizeDelegate,intptr&) <IL 0x0006a, 0xffffffff>
at System.Drawing.Image.InitFromStream (System.IO.Stream) [0x0008a] in /root/mono/mcs/class/System.Drawing/System.Drawing/Image.cs:297
at System.Drawing.Bitmap…ctor (System.IO.Stream,bool) [0x00006] in /root/mono/mcs/class/System.Drawing/System.Drawing/Bitmap.cs:113
at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap…ctor (System.IO.Stream,bool) <IL 0x00021, 0xffffffff>
at ImageResizer.ImageBuilder.DecodeStream (System.IO.Stream,ImageResizer.ResizeSettings,string) <IL 0x0004e, 0x00117>
at ImageResizer.ImageBuilder.LoadImage (object,ImageResizer.ResizeSettings,bool) <IL 0x000d2, 0x0093b>
at ImageResizer.ImageBuilder.BuildJob (ImageResizer.ImageJob) <IL 0x0005d, 0x0011f>
at ImageResizer.ImageBuilder.Build (ImageResizer.ImageJob) <IL 0x0004c, 0x000e3>
at NzbDrone.Core.MediaCover.ImageResizer.Resize (string,string,int) [0x00035] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Core\MediaCover\ImageResizer.cs:36
at NzbDrone.Core.MediaCover.MediaCoverService.EnsureResizedCovers (NzbDrone.Core.Tv.Series,NzbDrone.Core.MediaCover.MediaCover,bool) [0x000fb] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Core\MediaCover\MediaCoverService.cs:156
at NzbDrone.Core.MediaCover.MediaCoverService.EnsureCovers (NzbDrone.Core.Tv.Series) [0x00094] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Core\MediaCover\MediaCoverService.cs:109
at NzbDrone.Core.MediaCover.MediaCoverService.HandleAsync (NzbDrone.Core.Tv.Events.SeriesUpdatedEvent) [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Core\MediaCover\MediaCoverService.cs:168
at NzbDrone.Core.Messaging.Events.EventAggregator/<>c__DisplayClass3`1.b__0 () [0x00035] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Core\Messaging\Events\EventAggregator.cs:72
at System.Threading.Tasks.TaskActionInvoker/ActionInvoke.Invoke (System.Threading.Tasks.Task,object,System.Threading.Tasks.Task) [0x00000] in /root/mono/mcs/class/corlib/System.Threading.Tasks/TaskActionInvoker.cs:71
at System.Threading.Tasks.Task.InnerInvoke () [0x00031] in /root/mono/mcs/class/corlib/System.Threading.Tasks/Task.cs:548
at System.Threading.Tasks.Task.ThreadStart () [0x000d0] in /root/mono/mcs/class/corlib/System.Threading.Tasks/Task.cs:438
at System.Threading.Tasks.Task.Execute () [0x00000] in /root/mono/mcs/class/corlib/System.Threading.Tasks/Task.cs:514
at System.Threading.Tasks.TpScheduler.TaskExecuterCallback (object) [0x00000] in /root/mono/mcs/class/corlib/System.Threading.Tasks/TpScheduler.cs:58
at (wrapper runtime-invoke) .runtime_invoke_void__this___object (object,intptr,intptr,intptr) <IL 0x00052, 0xffffffff>

Native stacktrace:

Debug info from gdb:

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

This is running on a BananaPi (Debian armhf) running mono 3.10.1 which I compiled and have used without issue since September last year.

Any ideas appreciated

2

Which version of Sonarr? If its less than 2.0.0.2850 please update as this looks like an issue that was fixed already.

3

Sorry should have included that,

As of last night, I was running 2.0.0.2888, but this morning it has updated to 2.0.0.2889.
Have been receiving the nightly develop updates, over the last week, but the same error on each release.

LInk to logfile: http://pastebin.com/DE9RavKM

4

Looks like we have another compatibility issue with GDI+ on ARM. The plan is to pull that code and move it to Skyhook (our metadata proxy), but we haven’t started work on that just yet.

In the meantime you might be able to make Sonarr skip creating the smaller images by copying the full size image to the smaller ones:

banner.jpg

  • banner-35.jpg
  • banner-70.jpg

fanart.jpg

  • fanart-180.jpg
  • fanart-360.jpg

poster.jpg

  • poster-250.jpg
  • poster-500.jpg

That would need to be done for each series in <AppData>/MediaCover Where <AppData> is the AppData directory from System : Info

We would be interested to know if that works for the series you’re having issues with.

5

I will give that a try, and let you know the results.

I take it, the problem is occurring while it is working on the first tv series that sonarr is interrogating, as opposed to the second series in the list, when the error seems to occur.

6

Yeah, exactly.

7

Unfortunately that didn’t work.

It does get further through the refresh series, but MediaCover still seems to want to resize the jpg’s

Here’s a link to my most recent logfile.

http://pastebin.com/efpqYsf5

8

Looks like its trying to download images for series still, which would then convert them.

Did you overwrite any existing images (banner.jpg, fanart.jpg or poster.jpg)
?

9

I think out of the roughly 250 directories, 2 directories did not have the full set of (original) banner, fan art and poster jpgs.

While performing the suggested copies, there was 1 directory with a failed resized picture with a file size of zero bytes.

10

Was 7 Days missing images?

I don’t see any errors this time, but anything without a poster would be try to get one then resize, so it might be something with the two series that didn’t have them.

@Taloth Any ideas for this one?

11

Probably easier to locate libgdiplus.so and (re)move it, not sure if that prevents the crash but it’s worth trying.
(of course, make a backup and realize anything trying to use that lib will fail)

12

I’ll check tonight if 7 days was one of the directories without the full set of 9 files. Unfortunately that box does not have a GUI installed at all - purely command line

I’ll try Taloths suggestion and rename the library and let you know what happens. Luckily that system is primarily hosting Sonarr, so no big concerns if it breaks other applications

13

I tried to fully populate the 2 directories that did not have the full set of 9 files, but still had the crash. So I need to check through all of the directories again and see if any others are not fully populated.

As a temp measure I followed Taloths suggestion and that has given me a working solution.

Will provide more feedback when I have gone through all of the directories

14

Once gdiplus is disabled you really don’t need to copy the full image to make those 9 files.

Sonarr will automatically serve the full sized images if the smaller ones don’t exist. It just won’t be able to create those smaller files, but won’t crash on it either.

It’s obviously related to how it’s all compiled on ARM.

15

Thanks @markus101 & @Taloth. I was just curious to see what directory was causing the initial error.

Curious about the error, as I have been running that compiled library with Sonarr, since last September without error.
What changed within Sonarr to give me that sceanrio. Were the smaller images a new feature or was I just lucky i didn’t experience the error earlier,

16

It was a new feature to produce smaller images for quicker loading times on mobile (and for use my mobile apps).