Having trouble downloading certain issues

[ManOrMonster]

Mylar has been inexplicably not downloading some issues despite them being available. For instance, it said it couldn't find Rachel Rising 24 despite the fact that it is right there on usenet-crawler, with the same name and format as all the other issues. Multiple tries could not find it, had to download manually.

Today I added Knights of the Dinner Table and again it downloaded many of them but many of them it did not. I did notice that the issues it did not download had leading zeroes in the issue number (for instance, 026 or 001).

For search provider I'm using experimental to download from http://www.usenet-crawler.com/.

Also, I've noticed lately that I if I set an issue to skipped then back to wanted, I get this error in the log:

Uncaught exception: Traceback (most recent call last): File "C:\mylar\mylar\logger.py", line 141, in new_run old_run(_args, _kwargs) File "C:\Python27\lib\threading.py", line 761, in run self.__target(_self.__args, _self.__kwargs) File "C:\mylar\mylar\webserve.py", line 817, in queueissue raise cherrypy.HTTPRedirect("comicDetails?ComicID=%s" % ComicID) HTTPRedirect: ([u'http://localhost:8090/comicDetails?ComicID=9179'], 303)

[evilhero]

Try restarting Mylar and trying again. Whenever you get an exception error (or any kind for that matter), you need to restart Mylar as its not a graceful exception and will cause weird problems.

Not being on the development branch could also be a source of some problems, although I don't think anything recently involved searching related problems.

Also, experimental is its own nzb provider (it uses nzbindex.nl). So you're actually using two nzb providers to search.

The leading zeros shouldn't be an issue, but that may be related to the exception error not being handled gracefully and then not restarting.

If you can provide some logs as to show the searching and the failing it would help as well as I haven't a problem recently with searching.

[ManOrMonster]

I turned off experimental search, restarted Mylar:

2014-07-08 18:24:46 ERROR Uncaught exception: Traceback (most recent call last): File "C:\mylar\mylar\logger.py", line 141, in new_run old_run(_args, _kwargs) File "C:\Python27\lib\threading.py", line 761, in run self.__target(_self.__args, _self.__kwargs) File "C:\mylar\mylar\webserve.py", line 817, in queueissue raise cherrypy.HTTPRedirect("comicDetails?ComicID=%s" % ComicID) HTTPRedirect: ([u'http://localhost:8090/comicDetails?ComicID=9179'], 303) 2014-07-08 18:24:46 INFO Finished searching via :api. Issue not found - status kept as Wanted. 2014-07-08 18:24:46 INFO Could not find Issue 27 of Knights of the Dinner Table(1994) using Usenet Crawler 2014-07-08 18:24:45 INFO pausing for 0 seconds before continuing to avoid hammering 2014-07-08 18:24:45 INFO pausing for 0 seconds before continuing to avoid hammering 2014-07-08 18:24:45 INFO Shhh be very quiet...I'm looking for Knights of the Dinner Table issue: 27 (0000) using Usenet Crawler (newznab) 2014-07-08 18:24:45 INFO search provider order is ['newznab:Usenet Crawler']

[evilhero]

Try enabling fuzzy year search in the edit tab of the comic details screen. The issue has a 0000 year so it won't match up to anything (comicvine probably has incomplete data on it). Fuzzy the year to ignore the year for this series, click on Update then try searching again. You should get the matches. Don't use this option for series that have more than one volume as it wouldn't know which series is which.

Is this the development branch or master? I thought the raise error was addressed in the development build is why I'm asking.

[ManOrMonster]

I already set it to "Year Removal"... that should ignore the year, correct? My version is Version: 5696ab905cba5e92a4ec4b267371b45eaee4e463 (development).

[evilhero]

Yes year removal should ignore the year, so there's probably something else that's being missed. Can you post the relevant section of the mylar.log file that shows the search starting and the resulting failures to match?

Edit. Ok, nevermind that. I was able to fully duplicate this on my local box ;) Turns out that since Mylar does a store date/publication date comparison in order to ensure the issue is legit, having the year 'fuzzied' causes problems with the logic. I'm just working through the errors now (fixing one, causes a chain reaction of errors further down the processing line - so just have to work through them).