April 16, 20197 yr 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: Can you tell me where I've gone wrong here?
April 17, 20197 yr Author 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: 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
June 2, 20197 yr 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. 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: Docker settings: Routing Table: Docker Ethernet Port: Unraid Ethernet Port: Edited June 3, 20197 yr by karldonteljames
June 28, 20197 yr On 4/17/2019 at 4:41 AM, binhex said: see link below Q9. for examples on how to configure this- https://forums.unraid.net/topic/44108-support-binhex-general/?do=FindComment&comment=433612 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?
June 29, 20197 yr Author 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 postSent from my EML-L29 using Tapatalk
July 1, 20197 yr Hi, I’ve noticed very high RAM usage all of a sudden! Anyone else noticed this? Was there an update recently? cheers, Tim
February 22, 20206 yr 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). 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. Sab Connections: Plex Connection: Configuration Details for Lidarr (same as my Sonarr and Radarr essentially):
April 17, 20206 yr 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). 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. Sab Connections: Plex Connection: Configuration Details for Lidarr (same as my Sonarr and Radarr essentially): I'm having the same issue as well. I wish this had more support documentation for use in unraid.
April 26, 20206 yr 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
April 26, 20206 yr 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.
April 26, 20206 yr 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
April 28, 20206 yr @trurl and @Squid thanks for the reply and advice on checking out the lidarr github. I'll check things out over these and see if it's a known issue / bug.
April 28, 20206 yr 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.
April 30, 20206 yr @GeekMajic that may be the issue. I've posted a bug report onto the Lidarr GitHub asking about it and whether it's a bug or potential feature request. Thanks for the info,
May 8, 20206 yr 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 May 9, 20206 yr by thejasonparker
May 12, 20206 yr 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?
June 6, 20206 yr 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?
August 3, 20205 yr 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
August 21, 20205 yr 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 August 21, 20205 yr by deadnote
September 23, 20205 yr 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
December 19, 20205 yr Is this docker still supported? Mine say's "not available" under the docker tab.
February 23, 20215 yr I am trying to sync this list - https://www.last.fm/tag/best+albums+ever/albums so I created a list within Lidarr that looks like this, but it doesn't work. What am I doing wrong? Thanks
March 31, 20215 yr Is this docker going to be updated anymore? As I see there has been a new version of Lidarr available for a while now? Cheers, Tim
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.