Ongoing avistaz asian series not grabbed

Sonarr version (exact version): 2.0.0.4949
OS: Win server 2012
((Debug logs)): https://drive.google.com/file/d/0Bwc1KPPVNa_9MlhuMmh1V3NPaEU/view?usp=sharing

Description of issue:

These series have up to date listing in thetvdb yet they’re not being grabbed by sonnarr
i have listed thetvdb address and sample of release names for each of them

Infinity challenge and happy together stops at season 3 so probably safe to mark them as S03EXXX i think…

A log with the specific show is kinda hard to reproduce cause i have to trace when the new episode of the specific show appears on avistaz,
Luckily i found one,
15 hours before i post this, the return of superman’s was released, so i searched superman in all the logs and here’s what i got :

https://drive.google.com/file/d/0Bwc1KPPVNa_9MlhuMmh1V3NPaEU/view?usp=sharing

I don’t follow what you mean, if the season number is part of the release name it will be parsed, but if they’re using absolute episode numbers only then the absolute episode number needs to match.

I see plenty of the same warnings repeated:

17-8-20 22:27:33.7|Warn|ParsingService|Found daily-style episode for non-daily series: [276221][The Return of Superman].

But I don’t think those are for the The Return of Superman E196 170820 720p NEXT release (even though it has the airdate because Sonarr is parsing it properly: 17-8-21 06:46:36.5|Debug|Parser|Episode Parsed. The Return of Superman - 196.

I don’t see anything else because the logs are just the results of finding the specific string, so I can’t see what happened after it was parsed, but looking at TheTVDB these episodes are all missing absolute episode numbers, so Sonarr can parse them fine, but won’t ever match them to an episode (and never grab them because of it). Happily Together should actually work because the season number is in the release name, but until the mapping was added this morning would have failed because it is known as Happily Together (2001) on TheTVDB.

FYI, all this information shows up in debug logs, not need for trace logs which makes it harder to see because there is much more data and it covers less time.

So the only way to have them grabbed is by adding the absolute numbering to thetvdb?
Is there anyway to force sonarr to recognize “all seasons” type of numbering?

So the only way to have them grabbed is by adding the absolute numbering to thetvdb?

Correct.

Is there anyway to force sonarr to recognize “all seasons” type of numbering?

That’s what the absolute episode number is, a number that spans all seasons, these series are listed using seasons and episode numbers that don’t reset at 1, which is pretty non-standard and not something Sonarr handles in any special way.

https://forums.thetvdb.com/viewtopic.php?f=7&t=39245&p=118378#p118378

Asked in their forums and apparently there’s no way to import the numbering to absolute type,
If these are one time series e.g ending after 1 season i wouldn’t mind editing all of them.
Problem is these series have years of runtime and probably hundreds of episodes ahead…

Perhaps i could fork sonarr to identify these series based on all seasons numbering?

Edit : Or for a longer-term solution i think custom parser is really needed so users can parse their own series,
there are literally countless of tvshows with different naming formats, it will ease the burden for sonarr devs too…

There is an open issue for adding support for “Asian” series which this would fall under, probably a lot of edge cases though, since it’s absolute, but maybe not always.

That sounds like a can of worms and a support question waiting to happen, but this really isn’t a parsing problem, it’s a matching the parsed information to a series + episode.

Does series type make any difference?
I’m using standard type for these series.

Maybe add another series that relies on “all season” numbering?
Can sonarr crawl that data from thetvdb?

Series type alters how it’s searching and what it can do with parsed data (a series set to standard won’t import a file that uses a date as the identifier). In this case it doesn’t really matter because standard actually has data, but anime doesn’t because they lack absolute episode numbers (even though they are using an absolute episode number for the release.

Depends if they’re consistent enough in their scheme, Happy Together 3 E512 720p NEXT has a “season” number of sorts but also an absolute-like number. Which differs from Infinity Challenge E543 170819 720p NEXT that just uses an absolute-like number. If all the episodes, despite being in different seasons never conflict (season 2/3/x doesn’t restart at episode 1), then Sonarr could potentially have another series type that converts those episode numbers to absolute episode numbers (or on lookup it just searches by episode number). I’m not sure how that’d work with the anime type being similar, yet different.

hmm new episode of Happy together is still not grabbed

log :

https://drive.google.com/open?id=0B9f9Hk9Slq0WYjNSLWdVZUttMWc

So is that an ok for sonarr dev?
There seems to be more and more of series that only have all seasons numbering, here’s another one : http://thetvdb.com/?tab=seasonall&id=271760&lid=7

We need the logs that contain the RSS sync with that item, just the hits of that release in the file don’t help, it doesn’t show how it was processed.

Okay how? For us to implement?

Ok gonna send the log next week for the new episode.

Yes please :slight_smile:

Alot of asian series is based on “all seasons” numbering alone.
Found another one :
http://thetvdb.com/index.php?id=330764&lid=7&tab=seasonall&order=absolute
It would enhance sonarr’s flexibility if these are covered

The issue I linked previously would be the one to follow, but it’s not something I see Taloth or I picking up short term.

Bump then… found another tvshow with incomplete absolute season numbering… please consider this :slight_smile:

https://www.thetvdb.com/index.php?id=334993&lid=7&tab=seasonall&order=absolute
https://www.thetvdb.com/index.php?id=335785&lid=7&tab=seasonall&order=absolute

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