andy vt's tools & blog

I am using the profile 'Convert MKV TV Show to WTV' to convert and attach metadata from thetvdb.com.

Works fine most of the time but if failures occur it is *always* the lookup from thetvdb.com for the metadata that fails.

On manually checking thetvdb.com I can view the meta for the show I am looking for but the lookup still fails on retrying. I can retry several times to no avail but then the lookup will simply automagically succeed and it completes perfectly.

Is it just thetvdb.com search API that sucks or is there something that can be done? It's driving me nuts.

e.g. for a well-known Florida-based scientific crime drama series 10 episode 1

I use the '-v' option yielding the below trace:

                 [exec] Using following file as the target Metadata XML file: D:
\tmp\tv\mkv\XXXXXXXXXXXXX.s10e01.720p.x264.mkv.xml
                 [exec] Using input parameter as regular expression: (?<series>.
+)\.[s,S](?<season>\d+)[e,E](?<episodenbr>\d+)\.
                 [exec] Metadata provided by thetvdb.com
                 [exec] Found APIKey.
                 [exec] Found Series Name
                 [exec] Retreived Series Info
                 [exec] Unable to find Episode in TvDB Database.
                 [exec] Action did not complete successfully
                 [exec] Total Duration = 00:00:04.4301444

Hi - I was curious whether you ever resolved this issue?  It's making me crazy also.  If I copy the same, identifcal file into my watch folder *.mkv, 5 out of 10 times the episode will be found in the tv database and the correct metadata will be downloaded.  Even if I make no changes whatsoever to the filename.

I haven't resolved it beyond re-running the job. I looked into thetvdb.com and their search API though and I am certain that the filenaming convention is correct so no need to change filenames etc to get it working....

Turns out the API dictates that you obtain a list of mirrors from which you pick randomly to query the series and episode info - the dvrms action handles all this behind the scenes though. The error in the trace suggests that the series info xml does not contain the episode info - as for a cause I can only theorise that some mirrors are not kept up to date but without the ability to get some kind of trace output from the dvrms task to show the mirror being used and the series info xml queried I cannot verify this.

If the task could be configured to output trace showing the mirror names and the series info xml supplied it would be very easy to prove/disprove this theory [hint] by checking the series info xml to ensure it contains the episode xml - basically either identifying a bug in the dvrms code or proving that some mirrors are out-of-date.

Sorry I have nothing more like - do XYZ and it'll work 100% - I wish I did for my own sanity also hehe

This add-in is included with DTB but was actually written by someone else and he isn't supporting it anymore. If someone wants to take it over, I'm sure I can get the source.

I see it's a .Net assembly - I can probably take a quick look and add/amend the trace to be a little more informative on what's going wrong.

I don't have time to take over development or support for the component on a permanent basis though unfortunately but I'll see what I can do.

 Ok, email me and I'll get the source to you. bjdraw at google's mail.

I know what's causing the issue - it seems there's an odd bug in the thetvdb.com API which causes randomly selected http responses to be sent using gzip compression. This is in turn causes the parsing in the dvrmstoolbox task to barf because all it sees is the raw encoded string.

I've changed the code to use an http request to remove doubt by enforcing gzip compression on all responses and added code to decompress the responseStream before passing it to the parser.

I'll contact you privately to confirm how to submit the updated code for inclusion in the next dvrmstb release.

This is awesome news!  Thanks c0d3-m0nk3y for analyzing the code.  Is it possible to incorporate these changes into an existing copy of DVRMSToolbox?  I currently run 1.2.2.2 and have found it to be more reliable on my system than any of the newer versions including the 1.2.2.4.  Would prefer to take advantage of this update using my existing install if at all possible.

 Actions can be installed and distributed seperately.

I'll post a link to the latest .dll when I've finished testing it against DVRMSTB.

The project for Durrant.Common.TvDBMetaData has moved to CodePlex: http://tvdbmetadata.codeplex.com/

You can grab the latest release here: http://tvdbmetadata.codeplex.com/releases/77394/download/306360

Simply extract the zip into your dvrmstoolbox directory and overwrite the dll and xml files.

This was tested with 1.2.2.3 of DVRMSTB onwards but if you have any problems/questions feel free to raise them in the Discussions section of the project site and I'll do my best to get back to you a.s.a.p.

c0d3-m0nk3y:

The project for Durrant.Common.TvDBMetaData has moved to CodePlex: http://tvdbmetadata.codeplex.com/

You can grab the latest release here: http://tvdbmetadata.codeplex.com/releases/77394/download/306360

Simply extract the zip into your dvrmstoolbox directory and overwrite the dll and xml files.

This was tested with 1.2.2.3 of DVRMSTB onwards but if you have any problems/questions feel free to raise them in the Discussions section of the project site and I'll do my best to get back to you a.s.a.p.

Thank you SO MUCH for taking on this effort.  I must say that immediately upon installing your new code, the issues I've been experiencing with DVRMSToolbox 1.2.2.2 have completely and consistently gone away.  Amazing.  Although I'd love to use the latest and greatest (1.2.2.4), I've found that, for some odd reason, 1.2.2.2 conversion from MKV to WTV (which is all I use it for) seems to be the most reliable on my system with haali media splitter handling of MKVs.  Not quite sure why.  But if it's not broken, I figured why attempt to fix it by upgrading to a newer version.