Move commands on movie lists have seemingly no result

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load Queueman and navigate to the default Netflix Discs tab.
2. Hold on one of the movies in the list until the pop-up menu appears.
3. Select any of the Move commands ("Move Up","Move to Top" etc.)
4. The "Attempting to reorder queue" dialogue comes up and then 
disappears, but the queue list remains in the same order before the move 
command.

*What is the expected output? What do you see instead?
It is expected that either the list would be reordered to reflect the 
command, or if the queue reorder is failing an appropriate error message 
be shown.

*Did you rotate the screen just prior to the issue?
No

*What version of QueueMan are you using? On what version of Android? What
type of device?
I can reproduce this on my Droid Eris running Android 1.5 with the SenseUI 
and .0.9.7.1 beta of queueman and with the 2.0.1 Emulator and the latest 
queueman package compiled from trunk.

Please provide any additional information below.
They are both linked to the my personal netflix account.

Original issue reported on code.google.com by idigthedoug@gmail.com on 27 Jan 2010 at 3:56

[GoogleCodeExporter]

Thanks for the report.

By Golly your right!

I am not sure why this slipped by me, but I swear the move was working 
yesterday over
wifi. Here in the office today it is not.

Perhaps you can try over wifi, to help eliminate the iossue.

Otherwise if you want to share the stack trace seen in the emulator logs (using
logcat) is hyould be able to eliminate the issue.

Original comment by OlliTech on 27 Jan 2010 at 3:25

• Changed state: Accepted
• Added labels: Priority-Critical, Usability
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Weird - seems to be intermitten issyue.

If i refresh the disc queue, and move 2nd to top, it works, if i try again it 
fails.
I suspect something to do with the eTag not being updated so subsequent 
rerquests fail.

Original comment by OlliTech on 27 Jan 2010 at 3:29

[GoogleCodeExporter]

I am at the office right now and I was able to do some quick tests on my Eris.
Initially through 3G I had the same results as the original comment. I switched 
to a
wireless connection and tried it again with the same results. However, once I
refreshed the queue from the menu, the move commands worked flawlessly. I then
switched back to 3G and tried again and they still worked. After refreshing 
again
while still in 3G, it still works. 

So unfortunately that doesn't provide too concrete of a case, but at least it 
seems
like the wifi is a factor. 

I'll see if I can reproduce it again tonight and get you the logs.

Original comment by idigthedoug@gmail.com on 27 Jan 2010 at 4:23

[GoogleCodeExporter]

Can you comment on your signal and mobile type ? (ie 3 bars of 3g)

If i start the app with wifi I have no problems.
If I start the app relying on wireless carrier - error. 

It may not be significant, but my connection is a moderate Edge connection, and 
the
error is a 502 Bad Gateway.

I suspect  Netflix's API may be timing out during the transfer of data one way 
or the
other (slow connection) and the Hosting companies computer returns the 502.. 
But I
don't know that much about this stuff. (I of course being in bias of my code :) 
- SO
I am still actively looking into it on my side, and already have an open issue 
with
NF for 502 on other operations.

And If anyone else has this issue, please post connection details as well - 
thanks.

Original comment by OlliTech on 27 Jan 2010 at 11:05

[GoogleCodeExporter]

Just blew my own theory outta the water.  Move that took 25 seconds pass, but 
the
next one failed in 10.

Original comment by OlliTech on 27 Jan 2010 at 11:18

[GoogleCodeExporter]

I can't seem to replicate it today on my phone. I have about 2 bars of 3g. I 
started
the app fresh without any wifi same as yesterday, but now it's working. I 
didn't get
a chance to run on on my pc last night, but I'll see if I can tonight.

Original comment by idigthedoug@gmail.com on 28 Jan 2010 at 3:24

[GoogleCodeExporter]

This is definitely related to issue 17, though I'm sure of the actual cause. In
either case a q refresh seems to fix it short term.

Original comment by OlliTech on 31 Jan 2010 at 12:07