First of all, I want to apologize for not communicating better and not releasing an updated version to the develop branch. I have been pretty occupied with university and didn‘t have much time to spend on Radarr development :(
However, I think the new develop release with custom formats will be helpful for a lot of people. It allows almost unlimited customization of how Radarr rates releases, while still providing all the features you love about Radarr, such as upgrading qualities and having a cutoff defined. If you want to learn more, read the Custom Formats Wiki page or ask around on the discord channel :)
I also want to thank all the contributors, especially Qstick and rfgamaral for their continuous efforts to make Radarr better :) They have made a lot of PRs to help out! I also want to thank fryfrog and hotio for helping out on Discord, Reddit and Github with support requests.
To be - hopefully - more transparent about the development of Radarr in the future, I have tried to layout the roadmap for future development below.
Important: This roadmap is in no way complete or certain. It should only serve as an indication of how development continues
First, I want to explain some of the projects that you might have heard about. These are large feature sets, that have a code name. While the features of one project generally are released in one version together, these projects do not coincide with version releases to develop. If you want to keep track of a project and it‘s progress, take a look at the linked pages for each one.
Originally called profilinator / custom qualities, this is all about bringing as many customization options as possible to Radarr‘s auto download / upgrade / import system. It focuses mainly on the decision engine and how Radarr decides what constitutes a better release.
Most of the features originally planned have landed in nightly a few months ago and are now in the develop release. Check out the wiki page for a comprehensive guide of what options it will bring: Custom Formats Wiki. This project is mostly done already, however some backlog features / issues still need to be resolved.
This is all about bringing customization for folders / file naming as well as allowing you to have multiple files. This is only in early concept phase. I still have to work out the details, however, I can give a brief overview of how I think it will work:
NOTE: Nothing here is final, take everything with a grain of salt.
First of all, MediaFiles will be decoupled by quite a bit from their movies. In other words, Radarr can gather information about a media file, without needing to import it straight away. This should help with a few things internally, but also allow more flexibility and other features.
Secondly, Radarr will not require a path for a movie anymore. Rather, it will keep track of root folders for a movie, wherein a movie can be imported (with as many or as few subdirectories - also none! - as you would like). This will come with a few caveats though. For example, mismatched movie directories will have a harder time being recognized by radarr (If you have a good idea how to handle folders being mismatched, please let me know!).
Furthermore, Radarr will dynamically construct the path for import only when importing. Hence you can put all the metadata you want in there :) You will also be able to have no subdirectories for your movies.
DiskScanService will also have to be reworked, to allow for all of this. However, it should work better than before, since it will scan the rootfolders for all movies at the same time (I might add an option to disable disk scan service for the cloud users). Lastly, Radarr will now work with „DesiredItems“ in mind. In addition to a single profile and single root folder, you can add more profiles and more root folders for a movie. For every profile, there will be a root folder. Radarr will now go on and try to fullfill every „DesiredItem“, starting with the first one. This allows for a few interesting things:
- Have two profiles, one for only 1080p and one for only 4k. Add both to your Radarr movies, each one with a different root dir. Now Radarr will grab one 1080p and one 4k copy and put them in seperate folders.
- Have another profile for special editions. Radarr could then download both copies for you and put them in the same folder.
This is a rework of the Radarr API. In addition to making it run much faster, it will also receive a much bigger metadata database. I plan on „importing“ IMDB and Rotten Tomatoes ratings for now (only ratings, but plan on expanding this to other infos as well). In addition, I envision the possibility of allowing user submitted metadata along with voting on this information. If the voting exceeds a certain threshold, it will automatically be returned (as additional data) for every api call. This is similar to how the current mapping system works, but also for other things, such as runtime.
Furthermore, I plan on adding endpoints for bulk operations such as bulk importing and the daily movie refresh. This would allow for much much quicker movie refresh times (I expect an up to 100x improvement).
Also, more filtering options for lists and other endpoints are planned. Additionally, I plan on adding discovering similar movies, movies by same actor etc. The new API would also allow for a simple collection system, where you could add a collection by just adding it as a list.
I am currently in the process of writing the „database“ ingestion part. If you have experience with writing multithreaded python code that needs to process data and feed that to an SQL database, please let me know!
This is all about providing better localization support for metadata, but also searching foreign indexers. Currently, Radarr does some basic replacing for special characters, which is not always optimal when searching. For example, sometimes releases get missed, because of that. Additionally, the metadata language is tied to your profile. This would be improved partly by the new UI as well as API v3. So parts of this are tied to other projects.
No work whatsoever has been done here. If you have a good idea of how to handle replacing special characters (e.g. some users might wanna replace ö with oe, others don‘t want that) please let me know. My current solution would be to have a table in settings where you can define your own replacements.
This is all about rebuilding the current UI from the ground up. You have seen some mockups in the previous blogpost. Unfortunately, I am neither a good designer nor a web developer, so this project has been put on „ice“ for now. We might just pull in the phantom branch from Sonarr and start building on that, even though I would have liked to start fresh and build something tailored to Radarr.
If you have experience with web development and designing web applications (also from a UX perspective) and are interested in helping out, please let me know!
Now let‘s talk about upcoming versions! I will try to go through most issues in the next few weeks and reassign them their milestone in accordance with the following major versions. Releases to develop will continue as normally and should happen more frequently now.
Note: The milestones probably haven‘t been updated to correctly have all issues assigned.
Instead of waiting for all projects to be finished for v1.0, I have decided to release v1.0 as soon as the develop branch is stable. This means, that the current plan looks as follows:
- Fix any bugs that might pop up from the new develop release.
- Fix any bugs that are lingering around.
- Investigate memory leaks on linux?
- Release v1.0!
I hope to have this finished by the end of March 2019. However, with university it‘s probably gonna take longer than that.
Add integration with Radarr API V3.
No idea on a timeframe for this yet. This really depends on how quickly I can write the metadata ingestion for the API. The backend service will likely be live before v1.0 even and should be usable.
Most of the features from project proteus.
Also no idea on a timeframe for this yet. It will probably take more than a few months though. Project proteus will require a significant rewrite of some core Radarr (and Sonarr) parts. Even more so than Custom Formats did, and that took over half a year!
The planned projects are a major undertaking and will take a long time to complete. However, I am confident, that the resulting features will make Radarr even more awesome :)
Additionally, the newly released develop version not only features custom formats, but a lot of quality of life improvements. Some highlights of the changelog besides custom formats (see the full changelog here):
“Add Paused” option to Deluge and Transmission
The ability to set the number of threads (NOT SUPPORTED!) to use for tasks using THREAD_LIMIT environment variable.
Refactor MediaInfo tokens (new tokens for e.g. 3D, HDR, Atmos, etc.)
Ignore “special drives” from System » Disk Space
Unnecessary housekeeping commands consuming a lot of memory.
Finally, here is a video showcasing the possibilities with custom formats:
The Radarr Team