Some series/episodes are not been grabbed due to this message:
Is there a workaround or a temp issue?
“Series runtime is 0, unable to validate size until it is available”
I used to only see this with brand new shows (though fairly consistently with new streaming shows), but last night, it happened with both Snowpiercer (https://thetvdb.com/series/snowpiercer) and Penny Dreadful: City of Angels (https://thetvdb.com/series/penny-dreadful-city-of-angels), both of which are not new.
With the 24 hour cache at TVDB’s end, maybe Sonarr can assume a default value if the runtime is 0? To be fair, the runtime calculation could vary a lot depending on if the show is 30 min vs 60 min, so it would be a compromise.
Same for me on both of those series.
What is the 24 hour cache?
I’m glad that I’m not the only one having this issue. Same shows (PD:COA and Snowpiercer)…hopefully, enough people reports this TVDB cache issue with Sonarr and a fix can be implemented in the next update.
This one is not the tvdb api cache issue, it’s actually a bug on their end that cause the runtime field to be empty on the api in some cases.
Reported it a few days ago but no response yet.
Same issue with new series “Barkskins”
1 Like
Thetvdb mods can hardly be deigned to look into appeals from mere mortals on their own forums, so what makes you think they will look here, of all places, for an issue that is on their end? 
Thanks,
I will continue to manually load them to my download client.
Apparently they are probably extremely busy over at thetvdb to fix it.
I just noticed that thetvdb updated and fixed the runtime for all four episodes to all three series. I did not know that this was just a simple delay as I believed that it was an indefinite or permanent issue. If I had know this, I would not have open this ticket/request.
A little patience was all that was necessary.
It wasn’t a delay, it was a bug in their api backend code that was reported last saturday and fix last night on their end.
But no worries, they oopsie broke all the posters which will probably take 24h to resolve.
This has happened numerous times. Is there any way we could get Sonarr to allow user configurable run times? In other words be able to override certain critical info that can currently only come from thetvdb? Would be great I think.
A delay in fixing it which occurred prior to my latest post here which was at least 48hrs before you posted. I was checking it daily every few hours.
They are like most other devs (they fix one thing and break another); very common.
At the risk of sounding like a fanboi and going far off topic: that’s insulting to the sonarr devs, grouping them all together 
They maybe broke sonarr a handful of times in all the years it exists, and even then I’m talking about the dev branches where you’re supposed to live with it and accept the risk of living on the cutting edge…
I’d hire them for our dev team at work in a heartbeat.
It is still a fact that no one is perfect and therefore mistakes are made by ‘everyone’ and ‘anyone’ at one point or another regardless of grouping.
I have worked with and for devs with years of experience that sometimes fix one thing while at the same time break something else.
I interpreted your post as if you were talking about the natural api delay they have. Not them taking 6 days to notice our post and fix the actual code.
As for good vs bad devs. Bugs happen, but way too often we have to point them at the bugs and get no response for a fairly long time, or any at all.
What ticks me off is that it took them days to fix it, and fixed it halfbaked, returning incorrect runtimes (albeit close to the expected one). They said they ‘fixed and tested it’, no they did not test it… all the 3 series posted in the thread had wrong runtimes. Like they didn’t test the v3 api rollout, or a dozen other ‘fixes’ since.
I suspect they’ve been a bit stressed for the last 6 months, but they brought that onto themselves imo.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.