tman12

Members
  • Posts

    12
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

tman12's Achievements

Noob

Noob (1/14)

0

Reputation

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. Thanks for the update, I think what I'm going to do is pull the drive,format it and re-insert to rebuild from a blank state.
  6. SMART Test and System Log attached, I have been seeing the same issue this evening and previous few days so it occurred during the time period where the system log would pick it up. unRaid OS 5.0.5 Server Specs: Cooler Master CM Storm Series Trooper Case Cooler Master V700 700W 12V PSU 3 x Icy Dock MB154SP-B 4x3 SATA 6gbps Swap Cage MSI 970A-G46 AM3+ AMD 970 AMD Athlon II X2 270 CPU G. Skill 8GB DDR3 SDRAM Thanks! Sorry for not posting this info earlier. smart01.txt syslog.zip
  7. Are there other SMART tests to run? I already ran a long SMART test and received no errors. I do think it is probably a disk issue, but without any errors I'm not sure how else to tell.
  8. So I decided to pull the drive and put it back in to rebuild the data, still have the same problem. Any help is really appreciated, I have tried everything I can think of so far.
  9. Hello, I'm having an odd issue that appears to only be happening with one disk. When I copy a file from my PC over LAN the files copy extremely slow, they start out at a decent speed and then drop down to KB speeds. When playing high bitrate videos (30+ Mb/s) I'm getting constant buffering every few minutes. The disk is a Deskstar 4TB drive and I have another disk that is the same and does not have this problem. I have 10 disks in the array including parity. I have been attempting to copy some files from disk5 to disk8 (problematic disk) and Windows Explorer completely locks up and it can't even copy. I have no issues with any other disk in terms of copying/playing files so I thought maybe it was a disk problem or cable issue. I swapped out the SATA cable and even switched the port that it was plugged into. I ran short/full SMART tests on the disk and received no errors. I ran the command to test read/write speeds on all disks and every disk, including the problematic disk had normal read/write speeds (oddly enough the problematic disk had one of the highest read/write). I'm on 5.0.5 right now if that matters. I thought maybe there was an issue with not enough power since I recently installed two new disks so I spun down all the disk and spun up disk8 and still saw the same poor performance. If I'm playing a file from disk8 at high bitrate and I start to copy a file to disk8 I get buffering almost immediately. This does not happen with any other disk, and I don't think it should - writing and reading should not effect one another. I think the disk should be able to write at <40Mb/s and read at the same time without interrupt. My log file doesn't show any errors but I did notice an odd spin down reporting where the same disks are being called to spin down just a few moments after it has already been called to spin down. I turned spin down off for disk8 because I thought maybe this was the problem, still have the same issues. Dec 12 09:04:38 TAYLOR-NAS kernel: mdcmd (111): spindown 3 Dec 12 09:04:40 TAYLOR-NAS kernel: mdcmd (112): spindown 4 Dec 12 09:05:01 TAYLOR-NAS kernel: mdcmd (113): spindown 1 Dec 12 09:05:01 TAYLOR-NAS kernel: mdcmd (114): spindown 2 Dec 12 09:05:03 TAYLOR-NAS kernel: mdcmd (115): spindown 5 Dec 12 09:05:04 TAYLOR-NAS kernel: mdcmd (116): spindown 6 Dec 12 09:05:05 TAYLOR-NAS kernel: mdcmd (117): spindown 9 Dec 12 13:04:29 TAYLOR-NAS kernel: mdcmd (118): spindown 1 Dec 12 13:04:30 TAYLOR-NAS kernel: mdcmd (119): spindown 3 Dec 12 13:04:32 TAYLOR-NAS kernel: mdcmd (120): spindown 9 Dec 12 13:05:02 TAYLOR-NAS kernel: mdcmd (121): spindown 2 Dec 12 13:05:04 TAYLOR-NAS kernel: mdcmd (122): spindown 4 Dec 12 13:05:05 TAYLOR-NAS kernel: mdcmd (123): spindown 5 Dec 12 13:05:05 TAYLOR-NAS kernel: mdcmd (124): spindown 6 Dec 12 13:05:06 TAYLOR-NAS kernel: mdcmd (125): spindown 7 Dec 12 17:22:31 TAYLOR-NAS kernel: mdcmd (126): spindown 4 Dec 12 17:22:32 TAYLOR-NAS kernel: mdcmd (127): spindown 5 Dec 12 17:27:22 TAYLOR-NAS kernel: mdcmd (128): spindown 3 Dec 12 17:28:24 TAYLOR-NAS kernel: mdcmd (129): spindown 1 Dec 12 17:28:35 TAYLOR-NAS kernel: mdcmd (130): spindown 2 Dec 12 17:28:36 TAYLOR-NAS kernel: mdcmd (131): spindown 6 Any help is appreciated, I can't stand having this issue considering I have 3.5TB of video files on this disk and they are almost all high bitrate making them basically unwatchable. Edit: The disk spin down was interpreted wrong on my part, I wasn't reading the timing correctly. I run a scheduled job that moves local files onto the server every few hours so that would explain the spin downs occurring frequently.
  10. So I had my setup completely perfect and then I reinstalled unRaid and I think I forgot to set the allocation method so things got screwed up and I can't figure out how to get back. I have one share called Media, inside of that share I have several folders (TV, Recorded TV, Movies, Main Movies, TV Shows) so I set the allocation method to High-water with 40GB min free space and split level 2. There are 7 disks in my system and they all have a Media folder only at the root of the drive, however some of the disks have more folders than the others. So tower\disk1\Media\Recorded TV , but tower\disk2\Media does not have Recorded TV and when I browse to \\tower\media I don't see Recorded TV Basically it seems like Disk1 is dominating my Share, I went in and added Recorded TV folder to all disks and when I browse to \\tower\media I now have an empty Recorded TV folder. Also, I noticed I might have the movie on one disk and the fanart on another disk. So \\tower\disk1\media\Star Wars\Star Wars.mkv and \\tower\disk2\media\Star Wars\fanart - again when I browse the share I only see the data that was on Disk1 I am really struggling to figure out how I can fix this. Any help is greatly appreciated. EDIT: I was able to resolve the issue, I moved some files around and made sure the Media Share was at the root of every folder. Then I set allocation method and split level and rebuilt parity. Everything appears to be working correctly now.