tman12

Thanks @scottc however, I just tested with the binhex radarr docker and that is working properly. So this doesn't appear to be a Radarr specific issue, seems like a docker issue from my testing - unless I'm wrong. I did open a bug report on GitHub, but again I feel like it's more of a docker issue. I can't seem to find the AHD index file when browsing my cache share, do you know where those files are located at? I was curious to see if I overwrote the AHD index file with the one from Binhex if it will start working properly and then I can narrow it down to that. Does anyone else use AHD as a tracker with the linuxserver docker? I can't imagine that this is limited to my setup, especially since I'm using both the linuxserver torrent client and Radarr application.

I'm not sure if this is the correct place to post this particular issue, but the way Radarr passes a torrent from AHD (Awesome-HD) to the client (in my case, Deluge) the tracker URL is being sent with a space before 'announce'. This is causing the tracker status to report Error: Malformed announce. For example, when a search is performed and the file is located on AHD it is sent to the client directly or a blackhole directory and then picked up by the client. This functionality is working properly. The tracker URL for example is: http://moose.awesome-hd.me/##xxxxxxxxxxxxxx /announce You can see in that URL there is a space before the /announce, this is causing the error. The URL should be http://moose.awesome-hd.me/##xxxxxxxxxxxxx/announce and when manually editing the URL within the client to remove the space, everything works correctly. However, this kind of defeats the purpose of having automation. So I'm wondering, is there something in the configuration file for the AHD indexer that is incorrect and causing that space? I haven't tested any other Radarr dockers and I'm on the latest version for both linuxserver Radarr and linuxserver Deluge. I've tried sending the file both ways, directly to the client, and to a blackhole where it is picked up - both give the same space in the URL causing an error. I also haven't seen many topics about this when searching, but I don't see how this could be limited to my setup considering I haven't changed or edited anything. Any help or an update to the docker is appreciated! Tman12

I think I know what the issue is, but not sure if there is a way around it. /data/ is pointing to /mnt/user/Media/Downloads and my client is reporting //192.168.1.25/Media/Downloads so I'm assuming the remote mapping is not making sense of that because it's thinking that the mapping is /mnt/user/Media/Downloads and not my share that the client is reporting.

I cannot figure this out for the life of me... I'm running Sonarr in a docker with the following: /config -> /mnt/cache/Docker/sonar /data -> /mnt/user/Media/Downloads/ /media -> /mnt/user/Media/TV Shows/ Sonarr is able to grab the file and send to the client (uTorrent), but it cannot sort and rename. I have the settings turned on, it was working with a Deluge Docker so I know how to set that up correctly. The client downloads to \\192.168.1.25\Media\Downloads and I have tried to setup Remote Mapping because I believe that is what I'm supposed to do. Sonarr still is not able to see the downloads. Remote Mapping: Host: 192.168.1.25 Local: /data/ Remote: \\192.168.1.25\Media\Downloads\ Error: Request Failed: value [\\192.168.1.25\Media\Downloads\Episode.mkv] is not a valid *nix path. paths must start with / Parameter name: path Shouldn't my mapping help Sonarr see that \\192.168.1.25\Media\Downloads\Episode.mkv is actually \data\Episode.mkv Any help is greatly appreciated. I have also attempted this exact same setup using a mapped drive on the windows vm, replacing my server share with Y:\ and it still doesn't work.