Add Sonarr for Scheduling & Management to torrentserver

[ZeroCool2u]

Sonarr is a web application interface for management and scheduling of Torrents and Newsgroup files. It provides scheduling, renaming, and an effective interface for managing media sources and files. It interfaces directly with rtorrent, though I would suggest a switch to Deluge, but that's a separate issue entirely and I will submit an issue for that. Sonarr can be easily installed on Ubuntu and Debian distros with a few commands. See: https://github.com/Sonarr/Sonarr/wiki/Installation

I was planning on building my own Turnkey Linux Appliance from scratch until I found this. I believe the torrentserver appliance, and its utility, could be greatly improved.

[JedMeister]

Thanks for the feedback, but TBH I'm not completely sure about implementing your ideas. That is for a number of reasons:

1. AFAIK Sonarr only handles TV shows - so should we also install CouchPotato (or similar for movies) and Headphones (or similar for music)? What about ebooks and comics?
2. Seeing as Sonarr (and others) also support NZB, should we then also add a NZB client? If so which one? SabNZB? Something else?
3. From what I can gather Sonarr is written in C# so Mono is a dependency (which would add noticeable size to the appliance).

It really opens a whole can of worms if we start adding software; where do we stop? And what about users who prefer one of the SickBeard forks instead of Sonarr? I've read plenty of positive feedback for Sonarr but I've also heard many complain about it's shortcomings. Assuming that the functionality is similar, I think that one of the SickBeard forks (which AFAIK support torrents too) might be a better option? They are all written in Python so no additional dependencies required...!

Even if we were to go with one of the SickBeard forks, which one? SickGear (minimal development happening but still being maintained) or one of the SickRage forks (the majority of the developers moved onto a new fork which is under heavy development; whereas the original seems to be more focused on maintenance although some have reported that it's more buggy).

The same applies to your note/feedback re Deluge. We chose rTorrent/ruTorrent specifically as it uses the least resources and is the most scalable (written in C++ which is a more efficient language compared to Python - which Deluge is written in). FWIW though I personally use Transmission, just because it's what I swapped to when I ditched Azureus/Vuze years ago.

So I think it might be best to just leave the torrentserver appliance as-is and consider developing a new appliance. FWIW I have actually started work on an "All-in-one" mediaserver/torrentserver/nzbserver appliance (which I have tentatively called "Mediaserver-plus"). I haven't actually pushed my changes back up to GitHub yet but the repo is here: https://github.com/JedMeister/mediaserverplus

[ZeroCool2u]

I see where you're coming from and I think all of your points are valid and certainly have merit. I suggested Sonarr as a first addition, with my thought that couchpotato would come later. I think your idea for a "media server plus" is essentially in line with what I had in mind.

[JedMeister]

Ok, when I get a chance I'll push my changes back to GitHub, it's still incomplete but it's a start. If you are interested in developing it further it may make a good base?

I noticed that you've starred the repo so if you don't see me push my latest changes within the next few days, please feel free to give me a nudge! 😄