Grammar and missing column in table options

v3 Testing
#1

**Sonarr version (exact version)3.0.0.228:
Mono version (if Sonarr is not running on Windows):
OS:
Debug logs:
(Make sure debug logging is enabled in settings and post the full log to hastebin/pastebin/dropbox/google drive or something similar, do not post them directly here. Post in .txt not .doc, .rtf or some other formatted document)
**Description of issueGrammar mistake and missing column:

Under “Table options” (both in main overview page and inside of a series)
“Choose which columns are isVisible and which order they appear in”
Should likely be “Choose which columns are visible and which order they appear in”

Also size on disk should be a column option inside a series. And if there could be an option to remember or set globally to always expand the seasons that would be great. I can create issues on github or break these other requests into another post if necessary.

#2

Not even a grammar mistake, just a find replace gone awry.

Do you mean on the details page (for the episode)?

No, we want feedback here, 1 post is fine. Thanks!

#3

Yeah I figured something like that happend.

No, in the season list. In the table options where I can choose to show file path, audio codec etc. File size should be an option there.

Also, I installed/updated over v2. So far the only bug I’ve come across is when I click on the restrictions (settings->indexer) that I had setup in v2 to try an edit/delete them, this causes the ui to disappear entirely (white page)

#4

Not sure what your goal is, but if you hover over the quality in the status column, it will tell you the size. Maybe this helps?

#5

That does help but I would much prefer it as an optional column alongside the other current option in table options for episodes, Size gives a vague idea it the release is good quality or not. And yes I know you can set size limits.

#6

Please post a screenshot of the developer console’s console tab when that happens, we’ll need to see what the error is.

#7

Here’s the output of console

#8

Found another bug. Restrictions ARE case sensitive.

#9

That behaviour has not changed since v2, they are not case sensitive.

#10

Well I’ve just experienced the following:

Release with “NTb” in the title and it says “Does not contain one of the required terms” My required term is “ntb”. If I add “NTb” to the required words then it doesn’t have a problem with grabbing the release.

#11

I just tested that exact case and it’s working for me:

image

image
image1077×511 22.7 KB

image
image1079×589 62.6 KB

#12

I figured it out after testing exactly how you had yours configured. I was going though the process to show you why it didn’t work on my tag and had an idea that it might just be that it was the last term/word I had typed in and nothing to do with case. Sure enough that was it.

So the “bug” is this. If you copy and paste a list of words like so:
“word1, word2, word3”
it must not read the words correctly due to the spaces. Even though everything looks fine in the restrictions list with the green boxes of each individual word.

Same list without spaces:
“word1,word2,word3”
Works fine.

TL;DR
When copying a list of restricted words into the text box the list must be comma separated WITHOUT spaces.

#13

All the issues (including cleaning up pasted restrictions) should be fixed in the next release and a Size column will be available for episodes on the season details page.

I’ve taken note of the expanding seasons by default idea.

#14

Badass Dev! That was really quick. Thanks Markus

I’m going to try and use sonarr more now that I’m on v3, knowing it was coming out I didn’t want to get too used to v2 as my history has been sickbeard > sickrage > medusa / sonarr.

Currently I feel both (Medusa/Sonarr) have a balance of features that each make them have an advantage over the other in different areas. Hopefully in the near future some long awaited features will make themselves into each project. All the dev’s have lot on your plate.

Currently my biggest gripe coming from medusa is not being able give an order or priority to my indexers. I would prefer to use the ones that have a higher success rate first rather then wasting time/bandwidth etc try to get a successful download.

I do like that I can upgrade my web-rips to web-dl’s now! Unfortunately all my episodes are marked as web-dl as that was the only available label at the time.So they need to all be changed manually if they were in fact webrips. I wonder if it would be possible to use history to rename files that were in fact web-rips back to web-rips?

Holy grail personally would be able to upgrade episodes via words. So grab any 720p, then keep searching until i get a release that contains say “btn”. I know people on top level trackers won’t care for this but it would be really helpful for basically everyone else who cares about trying to get top quality files.

#15

Not the same, but you can now disable an indexer for RSS/automatic searching (where Sonarr picks the result it thinks is best) and only enable it for Interactive searches (where you pick the result you want).

There are probably ways to use the API to do that, but Sonarr isn’t going to trawl through the history to do it.

No short term plans to implement it right now, but there is:

#16

First, thanks for adding the size column in the seasons detail page.

As for indexer priority, my interest in it is different then most of the people that responded in that feature request. It would be more beneficial to put the indexer that has a higher/highest rate of successful downloads first in priority. Which would limit the amount of failed attempts being made on the “lower quality” indexers before a successful download is made on the better indexer(s). This would save time and bandwidth. This can either have a small or large impact, if there are many releases and the “good release” happens to be a last one picked it can take a long time going through all the incomplete ones first. On the flip side if sonarr does get a good release fairly early on then the impact is a lot lower.
Overall this likely come more into play on older files rather then new ones.

I was aware of that github feature request “Preferred words (more release restriction awesomeness)” and I’m trying to be patiently awaiting its release.

#17

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.