comictagger

This user has not updated recently.

39 8 18 1
Forum Posts Wiki Points Following Followers

comictagger's forum posts

  • 31 results
  • 1
  • 2
  • 3
  • 4
Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

@jslack Very cool. I really do appreciate all of the work there, and this amazing free service as well.

My build machine is currently being.. rebuilt, but once that's done, and I have some time, I want to profile the auto-tagging process on my app, to get a better sense of average API hits that are occurring, and get back you.

Also, I like the idea of communicating a cooldown time: that way the automated processes can respect that without having to keep hitting the API

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

#2  Edited By comictagger

@jslack I have no issues with the change itself. The limitation seems reasonable for the usage on my app, ComicTagger (https://code.google.com/p/comictagger/), which is similar in functionality to the Comic Vine Scraper plugin for ComicRack. The app currently does a lot of caching of results, so that for a tagging session, most of the searching doesn't need to be repeated. But of course, with a single key for all users, it's not enough. Since I can't control which users are using that key simultaneously, the best solution is let them provide their own API key.

(I actually posted an question on this board (with my prior user ID) about a year and half ago addressing this issue: http://www.comicvine.com/forums/api-developers-2334/api-key-usage-719514/#2 . With no response I went ahead with a single API key for the app.)

So, at any rate, my current concern is just getting hit with a change to the functionality of the CV interface without any warning, as I started getting postings on my issues forum and emails about a broken app out of the blue. In this case, I'm going to have add a configurable-by-the-user CV API key setting (and properly educate the user on the use of it), and handle the new error properly. None of this is rocket-science, but it takes time and testing on multiple platforms. With a little lead time, I might have avoided a temporarily broken app. So my only request is, going forward, give us all a little "heads up" on stuff like this.

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

@mrpibb@jslack It would be great if you guys could give us a little advance notice on this forum of API changes like this before going live. That would give those us who have apps that talk to the API some lead time on having fixes ready when the changes go up. Maybe just a new sticky thread "Upcoming API changes" with some minimal details on each update? Thanks!

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

#5  Edited By comictagger

I have problem too, maybe due to similar problems:

Searching for the 1955 Blue Beetle series: here: http://www.comicvine.com/blue-beetle/4050-1668/

The following two queries, while returning a number volumes with words "blue" and "beetle" don't return the one I'm looking for:

http://www.comicvine.com/api/search/?api_key=27431e6787042105bd3e47e169a624521f89f3a4&format=json&resources=volume&query=blue+beetle&field_list=name,id,start_year,count_of_issues

http://www.comicvine.com/api/search/?api_key=27431e6787042105bd3e47e169a624521f89f3a4&format=json&resources=volume&query=blue+AND+beetle&field_list=name,id,start_year,count_of_issues

If I do a query with only "beetle", it shows up:

http://www.comicvine.com/api/search/?api_key=27431e6787042105bd3e47e169a624521f89f3a4&format=json&resources=volume&query=beetle&field_list=name,id,start_year,count_of_issues

Like @matthewlupo I'm trying to figure out if I should be using the API differently, or if there are issues on your side. Just a few words to let us know if we should change our queries, or sit tight while you clear up things on your end would be immensely helpful.

Thanks!

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

#6  Edited By comictagger

Yikes, this is a big change! Did I miss a memo?

Like @cbanack asked, is this intentional? I'll add the "AND" fix if this is the way things are going to be.

Help us, @frobie-wan!

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

@frobie, thanks for checking it out. let me know if you want me to test something!

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

Another note on this:

I see that searching for "Avengers A I", (with the page parameter present) I also get a result. So I am guess that at some point the match algorithm replaces periods with spaces, rather than just removing them. Still unsure of how this relates to the paging, but wanting to add this bit of data.

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

Having the same problem searching for "Avengers AI" (no periods) via the API. In my app, I've been stripping all periods out from the search string that I give the to the API, since it tended to be work that way and was more forgiving. As @cbanack mentioned, I see that if I remove "&page=1", the query works. Also, if the periods are included ("Avengers A.I."), the search works, even with the page parameter!

Unfortunately, because of the issue described here I want to keep that explicit page parameter. I can't begin to guess how the search results are affected by pagination, though! Not sure what do here...

@frobie, you might be interested in this too?

Avatar image for comictagger
comictagger

39

Forum Posts

8

Wiki Points

1

Followers

Reviews: 0

User Lists: 0

Looks like this bug is there still there when searching on "amazing spider man", although the counts are now 107 and 106

I found that if you specify page=1 on the first query, you get consistent results. So, while I found a workaround, seems like there is still an issue there.

  • 31 results
  • 1
  • 2
  • 3
  • 4