[Support] binhex - Lidarr


binhex

Recommended Posts

On 2/16/2018 at 5:35 PM, FreeMan said:

@ayrtoo - What Frederick said.

 

Not only must your download client (NZB or torrent) put the files in /mnt/user/Torrents/Music, but it must name that location /downloads as well. If you're using, for example, the lsio nzbget docker, the path is mounted as /data, not /downloads and it won't work even if it's pointed exactly to /mnt/user/Torrents/Music. The downloader will tell lidarr to look for /data/folder, but lidarr doesn't know where to find /data, it only knows where to find /downloads.

 

That one's bitten me several times.

Hello all.

 

I've just started getting bitten by the remote path mapping as well.  I've got Lidarr configured exactly like RADARR and SONARR, and I understand that lidarr is funny about it's path mapping.  I just can't figure out how to fix it.  

 

I use SABNZBD for usenet and Deluge on a seedbox for torrents.  To transfer data from the seedbox to my local system, I use Syncthing.

 

The Deluge Seedbox download client has the Remote Path configured as /media/sdar/**********/private/deluge/music/

The local path mapping is /MEDIA_ROOT/downloads/calcutta/music/

 

The package is configured as follows:

image.thumb.png.9dc58631cf73805502b463f018f5d305.png

 

Can you tell me where I've gone wrong here?

 

Link to comment
12 hours ago, Moose_Flunky said:

Hello all.

 

I've just started getting bitten by the remote path mapping as well.  I've got Lidarr configured exactly like RADARR and SONARR, and I understand that lidarr is funny about it's path mapping.  I just can't figure out how to fix it.  

 

I use SABNZBD for usenet and Deluge on a seedbox for torrents.  To transfer data from the seedbox to my local system, I use Syncthing.

 

The Deluge Seedbox download client has the Remote Path configured as /media/sdar/**********/private/deluge/music/

The local path mapping is /MEDIA_ROOT/downloads/calcutta/music/

 

The package is configured as follows:

image.thumb.png.9dc58631cf73805502b463f018f5d305.png

 

Can you tell me where I've gone wrong here?

 

see link below Q9. for examples on how to configure this-

 

https://forums.unraid.net/topic/44108-support-binhex-general/?do=FindComment&comment=433612

 

Link to comment
  • 3 weeks later...

Evening, I'm trying to add a download client to lidarr, but I keep getting the error:
Unknown exception. The Operation has timed out.: 'http://192.168.12.216:8112/json'

Lidarr is setup with ip 192.168.12.215

Sonarr and radarr are both connect to deluge, and they are the same iprange (12.216 and 12.217)

 

Any idea why this might be? 

 

I'm seeing this is in the logs:

 

2019-06-03 08:00:29,991 DEBG 'lidarr' stdout output:
[Error] Deluge: Unable to test connection

[v0.6.2.883] System.Net.WebException: The operation has timed out.: 'http://192.168.12.216:8112/json' ---> System.Net.WebException: The operation has timed out.
at System.Net.HttpWebRequest.GetRequestStream () [0x0000f] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:910
at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000ef] in C:\projects\lidarr\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:68
--- End of inner exception stack trace ---
at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x001c8] in C:\projects\lidarr\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:102
at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in C:\projects\lidarr\src\NzbDrone.Common\Http\Dispatchers\FallbackHttpDispatcher.cs:53
at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x0007e] in C:\projects\lidarr\src\NzbDrone.Common\Http\HttpClient.cs:121
at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in C:\projects\lidarr\src\NzbDrone.Common\Http\HttpClient.cs:57
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.AuthenticateClient (NzbDrone.Common.Http.JsonRpcRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings, System.Boolean reauthenticate) [0x0005b] in C:\projects\lidarr\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:292
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.BuildRequest (NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings) [0x0006b] in C:\projects\lidarr\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:205
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.ProcessRequest[TResult] (NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings, System.String method, System.Object[] arguments) [0x00000] in C:\projects\lidarr\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:212
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.GetVersion (NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings) [0x00000] in C:\projects\lidarr\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:53
at NzbDrone.Core.Download.Clients.Deluge.Deluge.TestConnection () [0x00000] in C:\projects\lidarr\src\NzbDrone.Core\Download\Clients\Deluge\Deluge.cs:209


2019-06-03 08:00:29,997 DEBG 'lidarr' stdout output:
[Warn] LidarrErrorPipeline: Invalid request Validation failed:

I've made a little progress, If lidarr is running as "host" rather than on its own ipaddress it can connect to deluge. Can I add a path for the docker containers to connect to each other on their own subnet?

If I disable the VPN on deluge or Qbit, it will also connect, if using its own IP. (I'm using binhex-delugevpn)

I am able to ping the binhex-delugevpn container from the binhex-lidarr console, both by name and by IP address.

 

image.thumb.png.4f5bd7ca49d59049f59bfa715fb63e6d.png

 

Most of my dockers are assigned their own IP address in subnet, 192.168.12.0/24, This subnet is on a separate network port, running on VLAN 12. My Unraid server is on 192.168.10.0/24 (running a 4 port bonded network on vlan 10)

 

Dockers:

image.png.17427cab41ad40da6c04961988c99ac0.png

 

Docker settings:

image.thumb.png.b6cb4aa7648d8280ff91ad9143bf7491.png

 

Routing Table:

image.thumb.png.5cc75af575cc26e1230c738889ded1fa.png

 

Docker Ethernet Port:

image.thumb.png.97e59ce2b1efe7188b3fadae5c32bb84.png

 

Unraid Ethernet Port:

image.thumb.png.ef7880d5f018e0bd2e6248dabea09bb9.png

Edited by karldonteljames
Link to comment
  • 4 weeks later...
Binhex - I'm trying to research this same problem but your link is broken.  I tried to dig it out of the URL but was unsuccessful.  Would you mind reposting the link?
Documentation is now located on github see the link in the first post

Sent from my EML-L29 using Tapatalk

Link to comment
  • 7 months later...

Cheers... I am probably not the first to deal with this so I apologize if there is a simple fix buried in these threads. I have LIDARR setup and it's downloading files fine from within Lidarr, however, there are a couple of issues I can't figure out.

 

1. When using OMBI to request music I get the following error (first image).

image.thumb.png.3c2c4c88b3f8f60ca36ab774250e17a2.png

 

2. When files do download from SabNZB they stay in the "completed" folder instead of getting moved automatically to my media\music folder. I can't figure this part out. Here's some screen grabs maybe a smarter person than I can see what the issue is.

 

image.thumb.png.a4d786fbc7c28df2c46446aa75bc8202.png

 

Sab Connections:

 

image.thumb.png.47a8d584f820c1a67aefd06c46f44be2.png

 

Plex Connection:

 

image.thumb.png.6f356f433a231ad726b2cb7c2ff1db8b.png

 

Configuration Details for Lidarr (same as my Sonarr and Radarr essentially):

 

image.thumb.png.7245e4f54cb36e27b11b643ce4d26359.png

image.png

Link to comment
  • 1 month later...
On 2/22/2020 at 4:20 AM, JasenHicks said:

Cheers... I am probably not the first to deal with this so I apologize if there is a simple fix buried in these threads. I have LIDARR setup and it's downloading files fine from within Lidarr, however, there are a couple of issues I can't figure out.

 

1. When using OMBI to request music I get the following error (first image).

image.thumb.png.3c2c4c88b3f8f60ca36ab774250e17a2.png

 

2. When files do download from SabNZB they stay in the "completed" folder instead of getting moved automatically to my media\music folder. I can't figure this part out. Here's some screen grabs maybe a smarter person than I can see what the issue is.

 

image.thumb.png.a4d786fbc7c28df2c46446aa75bc8202.png

 

Sab Connections:

 

image.thumb.png.47a8d584f820c1a67aefd06c46f44be2.png

 

Plex Connection:

 

image.thumb.png.6f356f433a231ad726b2cb7c2ff1db8b.png

 

Configuration Details for Lidarr (same as my Sonarr and Radarr essentially):

 

image.thumb.png.7245e4f54cb36e27b11b643ce4d26359.png

image.png

I'm having the same issue as well. I wish this had more support documentation for use in unraid. 

Link to comment
  • 2 weeks later...

Hi @binhex

 

I've just setup my first unraid server and have today installed your sonarr, radarr and lidarr docker containers.

 

Sonarr and Radarr are working fine but I have an issue with Lidarr and the 'Album Folder Format'. For each artist I would like to have their work organised into 'Album Type' so it would look something like this...

Music/Artist/Album/Album 1 (2020)

Music/Artist/Album/Album 2 (2019)

Music/Artist/EP/EP (2020)

Music/Artist/Single/Single(2020)

 

So to do this I added the {Album Type} to the start of the 'Album Folder Format' field like this...

 

{Album Type}/{Album Title} ({Release Year})

 

But when I download any music or try run a 'rename' process it does not create the 'Album Type' folder structure but tags it onto the front of the title like this...

 

Music/Agent Orange/EP+Agent Orange (1980)

 

...when it should be like this...

 

Music/Agent Orange/EP/Agent Orange (1980)

 

I have checked all the file permissions and everything is ok and tried to replace the forward slash with a backslash but nothing seems to fix the issue.

Am I simply missing something or is this a bug?

Thanks in advance for any help and advice - Jason

Link to comment
3 hours ago, thejasonparker said:

Thanks in advance for any help and advice

If nobody on this forum has anything, you might check the website for the application (see the github link in the first post). binhex and our other docker authors just provide the docker for the application, and support for setting up the docker. The applications themselves are written by others and typically have their own website where support is provided for actually using the application.

  • Like 1
  • Thanks 1
Link to comment
3 minutes ago, trurl said:

If nobody on this forum has anything, you might check the website for the application (see the github link in the first post). binhex and our other docker authors just provide the docker for the application, and support for setting up the docker. The applications themselves are written by others and typically have their own website where support is provided for actually using the application.

As an aside, the context menu for any container will also contain (in most cases) a project link which will take you to the website for the actual application, and a more info link which will take you to the dockerHub page for the container

  • Thanks 1
Link to comment
On 4/26/2020 at 6:26 AM, thejasonparker said:

Hi @binhex

 

I've just setup my first unraid server and have today installed your sonarr, radarr and lidarr docker containers.

 

Sonarr and Radarr are working fine but I have an issue with Lidarr and the 'Album Folder Format'. For each artist I would like to have their work organised into 'Album Type' so it would look something like this...

Music/Artist/Album/Album 1 (2020)

Music/Artist/Album/Album 2 (2019)

Music/Artist/EP/EP (2020)

Music/Artist/Single/Single(2020)

 

So to do this I added the {Album Type} to the start of the 'Album Folder Format' field like this...

 

{Album Type}/{Album Title} ({Release Year})

 

But when I download any music or try run a 'rename' process it does not create the 'Album Type' folder structure but tags it onto the front of the title like this...

 

Music/Agent Orange/EP+Agent Orange (1980)

 

...when it should be like this...

 

Music/Agent Orange/EP/Agent Orange (1980)

 

I have checked all the file permissions and everything is ok and tried to replace the forward slash with a backslash but nothing seems to fix the issue.

Am I simply missing something or is this a bug?

Thanks in advance for any help and advice - Jason

I've been using Lidarr for awhile, I don't think you can separate Album Types into different subfolders. I'm pretty sure that the Artist name must be the base for all albums.

  • Thanks 1
Link to comment
  • 2 weeks later...

For those that are interested I got some help from the Lidarr github after posting my issue and have managed to get the 'Album Type' directory created to allow me to segment each artists' work like this...

 

/Artist/Album/Album 1 (2020)

/Artist/Album/Album 2 (2019)

/Artist/EP/EP (2020)

/Artist/Single/Single(2020)

 

To do this you need to add '{Album Type}/{Album Title} ({Release Year})/{track:00}. {Track Title}' to the 'Standard Track Format' and also this '{Album Type}/{Album Title} ({Release Year})/{Medium Format}{medium:0}/{track:00}. {Track Title}' to the 'Multi Disc Track Format' and then untick the 'Use Album Folder' option for each Artist which you can find by editing existing Artists. You also need to remember to untick this option when adding new artists.

 

This setup will also help if you want to have any other non-standard directory format.

 

All good and a big thanks to @ta264 on GitHub who helped me solve the issue :)

 

 

Edited by thejasonparker
Link to comment

So i had some issues last week with some of my dockers not being able to get into the gui, i ended up recovering my appdata from a backup and sonarr and radarr came back to life, but not lidarr.  Since i already did a recovery of the appdata, i'm thinking that i should remove the docker and try to reinstall it.  Will i loose my settings if i do this?

 

Here's my run command:

Command:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-lidarr' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '8686:8686/tcp' -v '/mnt/user/Downloads/':'/data':'rw' -v '/mnt/user/Downloads/Complete/Music/':'/media':'rw' -v '/mnt/user/appdata/binhex-lidarr':'/config':'rw' 'binhex/arch-lidarr' 

6cef6cb435b54c8676ea49f63c904f1bd7518edf6fb002f9daf3dce4bb5c3482
The command finished successfully!

 

Here's an error in the logs:

at NzbDrone.Core.Datastore.DbFactory.CreateMain (System.String connectionString, NzbDrone.Core.Datastore.Migration.Framework.MigrationContext migrationContext) [0x0000b] in <f339569e234a4fc1add8b9dab7a33d21>:0 is corrupt, restore from backup if available. See: https://github.com/Lidarr/Lidarr/wiki/FAQ#i-am-getting-an-error-database-disk-image-is-malformed

 

Anyone got any ideas before i remove and reinstall lidarr?

Link to comment
  • 4 weeks later...

I may just be doing something stupid. I setup LIDARR as i did SONARR and RADARR. LIDARR works fine, grabs the album downloads it, but it just makes the final folder in my downloads/complete folder instead of actually doing the final move to place it into my media folder. I manually moved it and plex read it all just fine. I have my root folder setup as downloads/complete as most people i've seen do, should this be changed? How do i find the media folder i setup?

Link to comment
  • 1 month later...

It seems multiple people here have the same issue and has anybody solved it? I have also installed SONARR and RADARR and they both move the files into my media folders but as others here LIDARR does not again I ask has anybody found a solution to this?

 

Thanks

Link to comment
  • 3 weeks later...

Hi

Since today, I can't add new band.

Am I the one with this problem ?

20-8-21 10:58:02.1|Warn|SkyHookProxy|Error: ProtocolError: 'https://api.lidarr.audio/api/v0.4/search?type=artist&query=BANDNAME'

[v0.7.1.1381] System.Net.WebException: Error: ProtocolError: 'https://api.lidarr.audio/api/v0.4/search?type=artist&query=BANDNAME' ---> System.Net.WebException: Error: ProtocolError
  at System.Net.WebConnection.InitConnection (System.Net.WebOperation operation, System.Threading.CancellationToken cancellationToken) [0x0015e] in /build/mono/src/mono/mcs/class/System/System.Net/WebConnection.cs:268 
  at System.Net.WebOperation.Run () [0x00052] in /build/mono/src/mono/mcs/class/System/System.Net/WebOperation.cs:268 
  at System.Net.WebCompletionSource`1[T].WaitForCompletion () [0x0008e] in /build/mono/src/mono/mcs/class/System/System.Net/WebCompletionSource.cs:111 
  at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func`1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000e8] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:956 
  at System.Net.HttpWebRequest.GetResponse () [0x0000f] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1218 
  at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x0011b] in <96b70a41daeb490db51c9994341a8d2b>:0 
   --- End of inner exception stack trace ---
  at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x001fb] in <96b70a41daeb490db51c9994341a8d2b>:0 
  at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x00080] in <96b70a41daeb490db51c9994341a8d2b>:0 
  at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in <96b70a41daeb490db51c9994341a8d2b>:0 
  at NzbDrone.Common.Http.HttpClient.Get (NzbDrone.Common.Http.HttpRequest request) [0x00007] in <96b70a41daeb490db51c9994341a8d2b>:0 
  at NzbDrone.Common.Http.HttpClient.Get[T] (NzbDrone.Common.Http.HttpRequest request) [0x00000] in <96b70a41daeb490db51c9994341a8d2b>:0 
  at NzbDrone.Core.MetadataSource.SkyHook.SkyHookProxy.SearchForNewArtist (System.String title) [0x0014a] in <f339569e234a4fc1add8b9dab7a33d21>:0 

Edet : Works this afternoon ! :)

Edited by deadnote
Link to comment
  • 1 month later...

So as of recent Lidarr has begun crashing, requiring a restart of the container to get things going again only for it to crash a few hours later. I have the log dump here for the last crash, it seems to be a memory error, didn't know if this is a container level issue or if this is a main branch lidarr issue.


 

2020-09-23 15:30:17,155 DEBG 'lidarr' stdout output:
* Assertion at lock-free-alloc.c:145, condition `sb_header' not met, function:alloc_sb, Failed to allocate memory for the lock free allocator



=================================================================
Native Crash Reporting
=================================================================
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.
=================================================================

2020-09-23 15:30:17,156 DEBG 'lidarr' stdout output:

=================================================================
Basic Fault Adddress Reporting
=================================================================
Memory around native instruction pointer (0x14c697d9f82f):0x14c697d9f81f d2 4c 89 ce bf 02 00 00 00 b8 0e 00 00 00 0f 05 .L..............
0x14c697d9f82f 48 8b 8c 24 08 01 00 00 64 48 33 0c 25 28 00 00 H..$....dH3.%(..
0x14c697d9f83f 00 44 89 c0 75 19 48 81 c4 10 01 00 00 5b c3 66 .D..u.H......[.f
0x14c697d9f84f 90 48 8b 15 e9 75 18 00 f7 d8 64 89 02 eb ba 67 .H...u....d....g

2020-09-23 15:30:17,156 DEBG 'lidarr' stderr output:
/proc/self/maps:
400ca000-4066a000 rwxp 00000000 00:00 0
40ec2000-40ed2000 rwxp 00000000 00:00 0
14c3bdaa9000-14c3bee00000 r--s 00000000 00:29 36611 /var/tmp/etilqs_ea5b35344a134efd (deleted)
14c3bee00000-14c3bef00000 rw-p 00000000 00:00 0
14c3bf100000-14c3bf200000 rw-p 00000000 00:00 0
14c3bf300000-14c3bf400000 rw-p 00000000 00:00 0
14c3bf500000-14c3bf600000 rw-p 00000000 00:00 0
14c3bf700000-14c3bf800000 rw-p 00000000 00:00 0
14c3bf900000-14c3bfa00000 rw-p 00000000 00:00 0
14c3bfb00000-14c3bfc00000 rw-p 00000000 00:00 0
14c3c0900000-14c3c0a00000 rw-p 00000000 00:00 0
14c3c0b00000-14c3c0c00000 rw-p 00000000 00:00 0
14c3c0d00000-14c3c0e00000 rw-p 00000000 00:00 0
14c3c0f00000-14c3c1000000 rw-p 00000000 00:00 0
14c3c1100000-14c3c1200000 rw-p 00000000 00:00 0
14c3c1300000-14c3c1400000 rw-p 00000000 00:00 0
14c3c1500000-14c3c1600000 rw-p 00000000 00:00 0
14c3c1700000-14c3c1800000 rw-p 00000000 00:00 0
14c3c1900000-14c3c1a00000 rw-p 00000000 00:00 0
14c3c1b00000-14c3c1c00000 rw-p 00000000 00:00 0
14c3c1d00000-14c3c1e00000 rw-p 00000000 00:00 0
14c3c1f00000-14c3c2000000 rw-p 00000000 00:00 0
14c3c2100000-14c3c2200000 rw-p 00000000 00:00 0
14c3c2300000-14c3c2400000 rw-p 00000000 00:00 0
14c3c2500000-14c3c2600000 rw-p 00000000 00:00 0

2020-09-23 15:30:41,773 DEBG 'lidarr' stdout output:

=================================================================
Native stacktrace:
=================================================================
0x55fda9163dea - /usr/bin/mono : (null)
0x55fda90fa32e - /usr/bin/mono : (null)

2020-09-23 15:30:41,773 DEBG 'lidarr' stdout output:
0x14c697f594d0 - /usr/lib/libpthread.so.0 : (null)
0x14c697d9f82f - /usr/lib/libc.so.6 : gsignal
0x14c697d8a672 - /usr/lib/libc.so.6 : abort
0x55fda9069a58 - /usr/bin/mono : (null)
0x55fda934c456 - /usr/bin/mono : (null)
0x55fda936640c - /usr/bin/mono : (null)
0x55fda93669cd - /usr/bin/mono : monoeg_assertion_message
0x55fda935843b - /usr/bin/mono : mono_lock_free_alloc
0x55fda931ba23 - /usr/bin/mono : (null)
0x55fda931a4ff - /usr/bin/mono : (null)
0x55fda931a57f - /usr/bin/mono : (null)
0x55fda9312b91 - /usr/bin/mono : (null)
0x55fda934375d - /usr/bin/mono : (null)
0x55fda9312349 - /usr/bin/mono : (null)
0x55fda93142d9 - /usr/bin/mono : (null)
0x55fda93148e0 - /usr/bin/mono : (null)
0x55fda9318ffe - /usr/bin/mono : (null)
0x55fda9319187 - /usr/bin/mono : (null)
0x55fda931c03f - /usr/bin/mono : (null)
0x55fda9308809 - /usr/bin/mono : (null)
0x55fda92e8f4c - /usr/bin/mono : (null)
0x55fda926ab1b - /usr/bin/mono : (null)
0x55fda9280356 - /usr/bin/mono : (null)
0x400ce84d - Unknown

=================================================================
Telemetry Dumper:
=================================================================
Pkilling 0x14c68f729700 from 0x14c67e59a700
Pkilling 0x14c63e0bd700 from 0x14c67e59a700
Pkilling 0x14c68f92a700 from 0x14c67e59a700
Pkilling 0x14c67d866700 from 0x14c67e59a700
Pkilling 0x14c63e2be700 from 0x14c67e59a700
Pkilling 0x14c5bfe72700 from 0x14c67e59a700
Pkilling 0x14c67e198700 from 0x14c67e59a700
Pkilling 0x14c67e399700 from 0x14c67e59a700
Pkilling 0x14c695379700 from 0x14c67e59a700
Pkilling 0x14c67ea9b700 from 0x14c67e59a700
Pkilling 0x14c63d8b9700 from 0x14c67e59a700
Pkilling 0x14c63daba700 from 0x14c67e59a700
Pkilling 0x14c697d63780 from 0x14c67e59a700
Pkilling 0x14c67c53a700 from 0x14c67e59a700
Pkilling 0x14c67d2fe700 from 0x14c67e59a700
Pkilling 0x14c63dcbb700 from 0x14c67e59a700
Pkilling 0x14c68f528700 from 0x14c67e59a700
Pkilling 0x14c63debc700 from 0x14c67e59a700
* Assertion: should not be reached at mini-posix.c:249
* Assertion: should not be reached at mini-posix.c:249
* Assertion: should not be reached at mini-posix.c:249

2020-09-23 15:30:41,797 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23379921680984 for <Subprocess at 23379921595640 with name lidarr in state RUNNING> (stdout)>
2020-09-23 15:30:41,797 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 23379921595696 for <Subprocess at 23379921595640 with name lidarr in state RUNNING> (stderr)>
2020-09-23 15:30:41,798 INFO exited: lidarr (exit status 0; expected)
2020-09-23 15:30:41,798 DEBG received SIGCHLD indicating a child quit

 

Link to comment
  • 2 months later...
  • 2 months later...
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.