'Have' Progress Bar Not Updating #671
Comments
Are you hitting the back button on the browser to return to the home page? It will cache the results until you refresh the browser screen (f5 usually). I don't believe it's a problem with development vs. master either as they're both in sync pretty much. Check the mylar.log file and see what it says after you do a Recheck Files? |
What status should have the bar 'fill'? Just downloaded? Just downloaded then archived? Or either downloaded or archived? |
Also a hard refresh (shift+refresh) doesn't seem to fix it - I thought it was a cache issue at first. The odd thing is it sometimes just disappears. And the big thing is most of my comics are 'archived' because of my 'workflow' - which is grab via Mylar or DC++, process into comicrack, the eventually 'move/sort' via a ComicRack plugin. |
Tried a recheck - basically said the items below. Progress bar still only showing 2 of 11. I also tried a different browser - so it's not a cache issue unless mylar has a cache and that's where the issue is occuring. 2014-04-17 21:34:56 INFO I have physically found 2 issues, ignored 0 issues, and accounted for 9 in an Archived state. Total Issue Count: 2 / 11 ...I also may be an edge case in that I sometimes use the wanted list as a list of things to grab from DC++ then mark things as downloaded. Noticed just now that it's throwing an error in the debug log (can't set as downloaded as file doesn't exist) when I set items as downloaded via that interface as I grab them from DC++. That MIGHT be the cause since they ARE getting set as downloaded still despite the error. |
This may have been fixed in a recent development commit. Are you on the development branch? |
Just rechecked (and recheckedout) and repulled to confirm - definitely up to date and on dev branch. |
Even if you're grabbing from outside of Mylar (dc++, torrents, nzbs, whatever) as long as Mylar has scanned them the tally count should increase accordingly. The Have count = downloaded + archived. I don't think marking them as Downloaded would affect anything count relayed, but if it's throwing an error then there's something not right that I'll have to look into further. If the issues aren't in the series directory because they've been moved elsewhere, is there a reason why you wouldn't mark them as Archived instead of Downloaded (since archived happens when it can't find an issue that it thinks is there, downloaded when the issue is physically present in the series directory) |
I figured out late last night what was going on - looks like it was using the right count for logging, but was using the incorrect one for the actual tally count. The fix will be in the next commit - probably late tonight if I can get to my laptop, otherwise tomorrow. |
Thanks! And I have to say you rock...getting a fix out that quick is just
|
… Issue number contains a negative, when renaming would rename to '00-1' (with padding enabled), FIX: When searching RSS cache for search results, would use both CBT and KAT regardless if only one was enabled (but either was used previously), FIX: Allow for some issues store dates to have a fluctuation of 1.5 weeks in order to account for some discrepencies in dates with the weekly pullist, FIX: (#671) Issues tagged as Archived (either manually, or by auto-checks) would not tally count the Have totals properly - it would not add the Archived count to the total Have Issue count.
Thanks for the kudos - hopefully the fix that just went up to the development branch fixes your problems with the Archiving feature. If it doesn't please let me know, and I'll try and work through some more iterations, as I tried a bunch of different variations but obviously I can't account for everything ;) |
Just checking now - appears to have fixed it at this point! Come next week On Sun, Apr 20, 2014 at 12:04 AM, evilhero notifications@github.com wrote:
Robert A. Zambon, Ph.D. |
So...just did a huge batch download of issues outside of mylar and marked stuff as "archived" via the "Wanted" interface and this bug reared it's head again. Everything is marked as archived in the comic itself, and I tried rescanning it, but it's not updating the little bar at all. What's weird is it's ONLY the ones I archived through the wanted page just today - other issues marked as archived via the main comic interface (possibly the wanted page awhile back as well) appear to be fine and register. Edit: Oooo...this is interesting. If I update one issue in a comic as archived, it rescans for real and the bar is fine. So, it seems marking issues as archived from the Wanted page did mark them as archived, BUT it didn't have the comic refresh and the recheck issues button on the comic interface isn't doing it appropriately w/archived content without setting an issue as archived. |
Good catch - that gives us a place to look. Did you have a debug log by chance, capturing both? |
Unfortunately, I do not have the log. Ok, this is interesting. Rescanning individual comics is now working...not sure what the heck changed. There ARE comics coming up with a status of "clear" though. Never seen that before. ...and now it's working if I go into manage comics, select all, and recheck files. I have NO idea what is going on now. Very confused. If I can reproduce again, I'll get logs. |
Screenshot of the "clear" please. Not sure the description you provided would do it justice at this point. |
Sorry, I went through and had everything rescan last night to address it. Where it said "clear" was within a comic screen, under the status for a specific issue. Note that it was that case as well (with a lower case c) and no i in a circle graphic/link either. Apologies for all the confusion around this. If I can get something more definitive I'll get the info - otherwise please just ignore for now. |
This may be me doing something wrong - but it seems the 'have' progress bar isn't updating correctly for certain series (for met at least). If I set it as 'downloaded' or 'archived' - the issues still show up as not had in the progress bar on the main page.
It's a minor issue, but it's a PITA when trying to identify what's missing, confirming the wanted list, etc.
The text was updated successfully, but these errors were encountered: