Fixing “Stuck” Downloads in the Comixology Windows App

The Comixology Windows app is an unfortunate disaster. What started off as a nice offline reader for the Comixology library has suffered from lack of any new features (like simple organization of owned content), and worse, serious regressions in functionality. The worst, and most popular “issue” that damn near everyone is facing, is the sudden inability to read downloaded content. For whatever reason, this issue has plagued me all week when trying to read Daredevil: Born Again. Sometimes, trying to re-download the content causes the app to get stuck and show no progress (and sometimes crash). Most people solve the issue by uninstalling the app, reinstalling, and then re-downloading their entire library.

That sucks. But there’s a slightly less sucky way.

    1. Determine which of your comics are in this ‘stuck’ state.

    The most common symptom is when trying to click on Read causes a black screen and a progress notification that never stops. Another symptom is that your list of actively downloading content shows no progress. Today, the symptom is my comic no longer appears on device (despite the fact that I was just reading yesterday).

    2. Close the Comixology App

    Either click on the X in the upper right corner, or if on a touch device you can drag the window to the bottom of the screen. Wait for it to spin before dropping (this will actually shut it down as opposed to suspending the app).

    3. Identify the location for where the comics files are

    For some reason, the root of the issue is that some metadata for the comic(s) is corrupted. I haven’t figured out exactly what, but clearing the files for the comic appears to work. So open File Explorer, and navigate to the %LOCALAPPDATA% folder. This is the folder that contains all of your Windows Store apps. Navigate to the folder that starts with “comiXology.Comics”.

    Then go into “LocalState”, and then the folder with your account name. This is the folder that contains the files for your comics.

    You’ll notice that the files are numbered with an ID, which makes it tricky to identify your comic. But you’ll also notice that for each ID folder, there is an associate ID.comx file. Navigating into each ID folder reveals a bunch of JPGs, which are the pages for the comic. One of the JPGs will the cover art. Make sure you enable thumbnails on that folder so that you can identify the cover image to locate your bad comic. Note the ID of the folder that you are in.

    4. Delete the files for the bad comic

    At this point, simply delete the folder and .comx file assocated with the ID you determined in #3 above.

      5. Start Comixology again

      When you restart Comixology, you should be able to successfully re-download the comic and enjoy.

BUT a few notes

  1. Once you start a download, leave the Comixology app running and active until the download is complete. I’ve noticed that I’ve ended up in this ‘stuck’ state if I switched apps or if the device went to sleep.
  2. Download one comic at a time. I also noticed that trying to download more than 1 or 2 comics at a time causes bad mojo. It’s very lame, but play it safe and just download one at a time.

It’s terrible that us folks on Windows with a large Comixology library are stuck with this terrible experience if we want to read offline. And since not all of my comics in my collection have backup PDF or CBRs available for download, I’m completely stuck. I really hope Comixology gets their shit together and invests some time in the Windows 10 timeframe to build a more stable universal app. Or even make the app open source so that others with time could build something that actually works.

Posted in Projects, testing | Tagged | 1 Comment

I Didn’t Mean to Break It, Really. :(

Some people feel that the tester’s job is to break software, whereas the developer’s job for performing testing activities is to make sure software works. This dichotomy, or disconnect, can sometimes be fun. Like yesterday…

At Mimeo.com, our ability to commit to fast printing and delivery times is driven by a huge backend infrastructure of services and LOB apps to help the production people get material printed and shipped with efficiency. One of our LOB apps is a simple web app that allows an order to be reprinted (sometimes, a few copies of an order can get messed up and we need to reprint some quantity to make it right). The UI for the tool is fairly simple. You enter an order ID in the textbox, give a reason for why it needs to be reprinted, and then the quantity for how many reprints you want. The quantity must be greater than 0 and less than or equal to the quantity in the original order.

reprint

Although the implementation details don’t really matter, I will say that the UI is an ASP.NET MVC app that’s just a façade, where the underlying controller makes calls out to other services. For this sprint, we had some work to do in one of the services responsible for actually doing the reprint logic. The UI did not change at all in this sprint, only the dependent WCF service logic changed.

The UI looks very familiar to any tester. It’s basically an interview question. Testing 101. You have a textbox and a button, how do you test this? How would you, dear reader, test this?

We’re at the end of the sprint, so our feature team decided to do a big group hug pair-coding/pair-testing session where we can all give test ideas and find/fix bugs quickly. And we started off with this reprint app. I happened to be driving the session at this point. The project lead asked, “Ok, what quantity should we try?” As the words exited his mouth, I just happened to start off with “0” in the quantity box. As soon I hit the Reprint button, the project lead said, “Wut did you just do?! Did you put in 0?? Don’t do that!” So, of course, the tool accepted 0, made the service call, and it ended up reprinting the entire order. Bug.

We then setup the order to reprint again. The project lead was driving the session this time and again asked, “What quantity should we try this time?” I answered, “The quantity for this order is 200 right? Let’s try 201.” He typed it in, and again, the quantity was accepted and passed down to the service, which printed 201 copies. Bug.

At this point, the team was dying laughing. Simple UI validation checks weren’t performed, and this was a tool that has been in use for several months. One of the devs said something to the effect of how this is why we have testers who can break the software.

But is that what I was trying to do? Was I purposely trying to give inputs to break the app? My first instincts when seeing a textbox is to explore boundaries. So something that takes in a quantity (presumably an int) should be explored with at least a 0, maxQuantity+1, -1, characters. All of these should first pop some sort of validation in the UI so that we catch bad input prior to any underlying service calls. Once I verify that basic validation is happening at the UI level, then we can test the meat with real values. That’s just how I think. I wasn’t trying to break anything. I was trying to explore the behavior of the app by entering bad input in order to learn what sort of instructional message we return back to the user, and to learn how the application itself reacts to bad input.

I don’t feel that testing activities are meant to “break” the software. I also don’t feel that the activities should solely be meant to verify that things work. Exploration is key in understanding how the software works (or should work), and to identify the potential gaps in expectations.

Posted in testing, Work | Tagged , , | Leave a comment

Herding Unikitties

Coaching kids is hard. I mean, really hard. Last week, I had the awesome opportunity to be a coach for the first time. I’m coaching my son’s Junior FIRST LEGO League team. I’ve never coached kids for anything before. Sure, I’ve done a few show and tells in my kid’s daycare, and read a book to his Kindergarten class. But I’ve never sat with a bunch of kids for an extended amount of time with the expectations that they had to listen to me.

Before the first practice, I envisioned this:

itn12897

But in reality, this happened:

mythbusters_herdingcats

And sometimes:

41e1738f6084e01b0d717688000263cf-room-full-of-cats-going-crazy

Holy hell, my repeated remarks of, “please take a seat,” and, “stop running,” were interpreted as “ZOMG-SHOWER-ME-WITH-MORE-LEGOS-ARRARRRHAHAHAHAHA-I-DON”T-KNOW-WHATS-HAPPENING-SUGAR-AND-PRETZELSTICK-LIGHTSABERS!”

The practice was pretty awesome. It was absolutely amazing to see a bunch of kids who didn’t know each other, almost instantly bond like some sort of human katamari (it literally looked like rolling a human katamari sometimes). The LEGO really interlocked these kids. And yet, every kid was completely different. Right away, we observed the clever thinkers, the shy ones, the rebels, and the storytellers.

I learned a lot in this first practice.
1. Adults are easier to coach than kids. Adults will mostly stop what they’re doing, pay attention to the speaker, and do as they are asked. Kids don’t. Full stop.

2. Use the session plan in the LEGO coach’s materials as a very general idealistic guideline. There is absolutely no way in hell that 6 year old kids will spend an hour and half going thru all of that material. We did an initial brainstorm for team names, but couldn’t get their attention spans in check to actually decide on a name yet. Forget making a logo in that first session. And once the BuildToExpress kits were introduced, we only made it thru 3 of the challenges.

3. Keep things moving. This is where I failed. I came in with a bulleted agenda based off of the lesson plan in the coach’s guide. I tried to go through the program and discuss the six “core values” for the program (e.g. “We are a team,” “We share,” etc). But I didn’t effectively cater to the short attention spans of the 6 year olds. And once the BuildToExpress kits were introduced, it was game over – it was buildin’ time.

4. The kids want to build with LEGO, so let them. Before the kits were given, they spent the whole time, just looking at the big tote of materials in the class asking, “When we can use the LEGO??!?” instead of listening to what I was trying to say. Once the kits were introduced, it seemed like they weren’t listening to what I was saying, but they sort of were. They’re heads were down and focused on building, but they would actually pick up on some of the words coming out of my mouth. The kids are there for the LEGO. So let them build. The stuff for the season challenge will come in time.

5. The most important thing is to make sure the kids have fun. I found it important to get all of the kids involved, creating, and sharing.

We spent quite a bit of time (probably too much time) brainstorming team names. The kids were all antsy (see the third picture above) and it was clear that they wanted to get they’re energy out. So we tabled the brainstorm and just had them open the BuildToExpress kits and start having at it. The decibel level in the room quickly dropped for the first time. We just let them play with the kits for a good 10min or so and not give any guidelines or challenges. I finally gave them a 2 minute warning and told them that they would all have to present their build. I had each kid do the following:

1. What’s your name?
2. What grade are you in?
3. Who’s your teacher?
4. Tell us 1 awesome thing that happened today.
5. Tell us about your LEGO creation.

This not only got each kid to initially present to the team, but served as a pretty good introduction. I’m pleasantly surprised that even work. Having each kid go through the intro actually took a lot longer than expected. A few of the kids got pretty…enthusiastic… about the story behind they’re model. Some of the stories were pretty elaborate. It’s hard to cut off a kid’s story, especially when they’re so excited and proud.

Next we went into the challenge cards. Sticking to the “2-3min” is nigh impossible. Every time I said that time is up, it was pitchforks and yelling of “MOAR TIME PLZ!” It’s more like 5-6min for the build. And again, the sharing part took way long. I found it super important to make sure everyone was involved. If someone was too shy to share or was stuck, I tried to lead them along with questions to get them thinking and building. We got through 3 builds and decided it was time to try to nail a team name from the initial list we had at the beginning of the practice.

graph

Yeah, the team name didn’t happen. We were about an hour into the practice with about 20min still left, but the kids were done. My voice was background noise to their running and yelling. They were done with sitting, done with LEGO, done with humanity. I’m talking Lord of the Flies.

LordOfTheFlies 7

Ok, I may have exaggerated a tiny bit. In all seriousness, I’m really excited about this opportunity. It’s really cool to see the kids thinking and creating and working together. And this year’s challenge, Redefining Learning, looks incredibly fun. I’m super excited to see how this season goes.

Posted in JrFLL, LEGO, Projects | Tagged , | Leave a comment

Oh snap – I denied “Everyone” permissions from my MSMQ

Yeah, so in a brilliant move today, an MSMQ on my QA box was accidentally destroyed maliciously when I set Deny permissions for “Everyone”. Oops. Luckily this StackOverflow response from user Houman saved my ass. Simply navigate to C:\Windows\System32\msmq\storage\lqs and delete the queue. The names are cryptic, but lucky for me, that was the only queue that I touched and was able to locate it by ordering by timestamp.

Oops.

[Blogging this so I can easily find this solution the next time I do this same boneheaded move.]

Posted in testing, Work | Tagged , , | Leave a comment

Inspiration in Everyday Things

I was lucky enough to attend CAST 2014 last week. CAST is a wonderful conference bringing some of great minds of the testing community together under one roof. Michael Larson has great summaries of the two day conference on his blog. Out of all of the great keynotes, Ben Simo’s talk was probably the most entertaining from a purely geek perspective.

 

Ben’s keynote, “There Was Not a Breach; There Was a Blog,” shares his experiences visiting HealthCare.gov and the wonderful ways in which the site totally failed. Ben goes in depth into the functionality issues, usability problems, and potential security implications of how the site was implemented. The talk was truly inspirational. Ben captivated everyone in the room, going step by step into what he tried, what he found, and why it’s a problem. Exploratory testing at his finest. My key takeaway from this talk and what really inspires me is this – any one of those testers in that room could do this, too.

If you watch Ben’s talk, he starts off talking about the tools he used. Everything he used is pretty much on your machine already:

  • Chrome and IE? Check.
  • Developer tools? Checkit’s part of the browsers!
  • Fiddler? This was the only ‘special’ tool that had to be installed. And this is free. And if you’re a tester who’s testing a website or app with network connectivity, you should have this on your machine already. Check.

He didn’t have a spec or user stories. He didn’t have source code available. He had no special access to internal builds, log files, etc. He wrote no “automation” or code of any kind to find bugs. Everything he did was public facing using the tools that we all [should already] have. And that to me is inspirational. And it should be inspirational for you, too.

Posted in testing | Tagged , | 1 Comment

AppFabric v1.1 Installer Hates You

[Blogging this because we’ve hit this a few times at work in the past 3 months]

If all attempts for installing AppFabric v1.1 fail with the ever helpful 1603, look in your %TEMP%\AppServerSetup1_1_CustomActions(datestring).log file [where datestring is the last time you invoked the installer]. You may see a message like this:

6/23/2014 11:32:45 AM EXEPATH=C:\Windows\system32\\net.exe PARAMS=localgroup AS_Observers /comment:"Members of this group can observe AppFabric." /add LOGFILE=C:\Users\me\AppData\Local\Temp\AppServerSetup1_1_CustomActions(2014-06-23 11-32-31).log
Error: System error 1379 has occurred.
Error: The specified local group already exists.
ExitCode=2

Answer: Visit this StackOverflow answer: http://stackoverflow.com/questions/16655899/appfabric-installation-error-code-1603. Basically, blow away the AS_Observers and AS_Administrators local groups. Then try to run the installer again.

Then go grab some ice and Tylenol. That past hour of slamming your head on your desk probably left a bruise.

Posted in Work | Tagged , , | Leave a comment

Better Workaround for AppFabric Cache’s Tracing Hatred

As a follow up from my last post, here’s a simple extension method to forcibly restore the default trace listener every time you invoke an AppFabric Caching Administration Management cmdlet. It’s not the prettiest code, but it’s functional:

Posted in Work | Tagged , , , , | Leave a comment