PDA

View Full Version : Poor Wireless Causes Most Bugs?



sdonham
2007-10-15, 12:09
I've had my jive remote for maybe 5 hours now and I've already hand written a list of bugs and quirks for me to look into. Being a software engineer, I know how annoying it is to get a bug report that just says "Feature 'x' doesn't work" so I'm holding off on submitting bugs until I find a possible cause for them and a detailed explanation as to how to reproduce them.

Here's my question: Could many bugs be caused by a poor wireless signal? For instance, currently, while standing next to my router, the volume up/down buttons work perfectly. Step a few feet away and pressing volume up causes the volume to go 100%. If I return to the wireless router, volume buttons return to normal behavior. I've tested a dozen times by now.

I'm installing ethereal now to check out the volume signals sent or received, but I've noticed this behavior with a number of functions (i.e. poor reception causes the middle "select" button to appear as if it were pressed multiple times).

Any thoughts?

Skunk
2007-10-15, 14:02
Does your router work well in other wireless applications?

I'm getting a full signal on the second floor (with the bathroom door closed if that's not TMI) and the router in the basement. It also works from the hammock outside.

My volume control seems better behaved than a couple weeks ago, but I also discovered the 'press up or down once and adjust with the scroll wheel' trick, which seems less prone to sudden 100% syndrome.

SuperQ
2007-10-15, 14:06
I've had my jive remote for maybe 5 hours now and I've already hand written a list of bugs and quirks for me to look into. Being a software engineer, I know how annoying it is to get a bug report that just says "Feature 'x' doesn't work" so I'm holding off on submitting bugs until I find a possible cause for them and a detailed explanation as to how to reproduce them.

Here's my question: Could many bugs be caused by a poor wireless signal? For instance, currently, while standing next to my router, the volume up/down buttons work perfectly. Step a few feet away and pressing volume up causes the volume to go 100%. If I return to the wireless router, volume buttons return to normal behavior. I've tested a dozen times by now.

I'm installing ethereal now to check out the volume signals sent or received, but I've noticed this behavior with a number of functions (i.e. poor reception causes the middle "select" button to appear as if it were pressed multiple times).

Any thoughts?

It sounds like the device needs to monitor for packet loss (I think there are kernel counters it can read to find this out) and latency problems. Then it can warn the user when signal is poor.

bpa
2007-10-15, 14:18
How about logging the wifi strength with this script
http://forums.slimdevices.com/showthread.php?t=39214

and then send Caleb the results to improve JHB.

sdonham
2007-10-15, 15:02
Does your router work well in other wireless applications?
Other wireless devices have had no problems. The remote seems a bit weak but I suspected that from reading the other posts.



My volume control seems better behaved than a couple weeks ago, but I also discovered the 'press up or down once and adjust with the scroll wheel' trick, which seems less prone to sudden 100% syndrome.
Hey! I didn't know you could that. It DOES work better this way.



It sounds like the device needs to monitor for packet loss (I think there are kernel counters it can read to find this out) and latency problems. Then it can warn the user when signal is poor.

That's exactly what I was looking into. I have been able to confirm that adjusting the volume with no reception, then walking back into the room with reception causes a sudden burst of volume controls. Haven't tried this yet with other buttons as the remote now locks up, and often, when I lose reception. I would love to gain access to the remote during this time, so I can figure out what goes on, but I lose my SSH connection as well when it locks up.



How about logging the wifi strength with this script
http://forums.slimdevices.com/showthread.php?t=39214
and then send Caleb the results to improve JHB.

I'm trying that now, but I need to get a SD card that works with the remote(I think, reading through his directions now).

As a side note, and completely unrelated, could someone explain why there are 4 separate jive processes running on the remote? Sometimes there are 2 or three (usually three), but I've seen up to 4. Just curious where they are being spawn.

sdonham
2007-10-15, 18:52
Scratch that. I've got a TCPdump of the messages for volume control between the remote and server. Clearly, there are TONS of duplicate/retransmission packets, but it looks perfectly handled in standard TCP:
1. remote sends volume
2. server sends ACK (never gets to remote)
3. remote resends duplicate/retransmission volume packet
4. server sends Dup. ACK (again, never gets to remote)
5. remote resends duplicate/retransmission volume packet (3rd time)
6. server sends Dup. ACK (remote gets it!)
7. remote sends ACK to server's duplicate ACK..

I can post the dump if anyone is curious, but I doubt it will explain the volume jumping 4-5 notches with a single button tap. Granted, I'm a little rusty reading these TCP dumps, but it appears to be normal TCP behavior.

peterw
2007-10-15, 22:25
I have been able to confirm that adjusting the volume with no reception, then walking back into the room with reception causes a sudden burst of volume controls.


Sounds like the Jive HTTP queue. I'm interested to see how this works. At first I guessed and hoped that the Jive platform would be fairly lightweight, like the Squeezebox. I guessed that the SlimServer host would provide the Jive client the data needed to render most of the UI. But Jive seems more akin to Stuart's mclient app from the MVPMC project -- a relatively "fat"/"smart" client that essentially uses CLI to try and control and monitor Slimserver.

I think you're seeing the results of a "blind queue" and wifi reception problems. In the old IR model,
1) the command was received by a reliable listener (the Squeezebox, which has to have stable network to play music)
2) commands did not queue. Point IR remote at black pillow, and any button press is missed/lost.

I expect the scroll wheel approach works better because individual Up/Down button presses are pushed in a queue to send volume_up or volume_down commands, and the scroll wheel adjustment probably uses 100% client side Jive/lua code to figure out what volume you want and then send a simple mixer command to set a specific volume.

ISTM --from what I'm reading-- the Jive command queueing could/should be improved. Jive JSON/RPC/HTTP requests that are triggered by user interactions should be discarded after some very brief period, not queued, to behave more like IR. It might be very cool to have a virtual "ack light" on the screen. Press a button on the Jive remote, and when it successfully connects to Slimserver and sends the appropriate command (perhaps before receiving any response), the "ack light" would flash -- like the "xmit" LED on many IR remotes, so you'd have simple visual acknowledgment that the code was received. Green O indicates code received, red X indicates command timed out & will be ignored.

-Peter

rtitmuss
2007-10-16, 02:05
Sounds like the Jive HTTP queue. I'm interested to see how this works. At first I guessed and hoped that the Jive platform would be fairly lightweight, like the Squeezebox. I guessed that the SlimServer host would provide the Jive client the data needed to render most of the UI.


Jive is thicker than a Squeezebox, but it's not a total thick client. Slimserver does provide much of the data needed to render the UI, but Jive can also includes some built-in functionality including the volume control.


ISTM --from what I'm reading-- the Jive command queueing could/should be improved. Jive JSON/RPC/HTTP requests that are triggered by user interactions should be discarded after some very brief period, not queued, to behave more like IR.

You could be right, but at the moment there are some underlying performance problems that are not helping here: wireless range, wireless driver inefficient/reliability, old kernel, non-optimal toolchain and inefficient threading. We're working on fixing those first, and then will look for application level optimizations to make this thing fly :)

Cruzan
2007-10-17, 00:18
...

Could many bugs be caused by a poor wireless signal?

...

Any thoughts?

My Jive remote hasn't worked since r616. My router reports a signal to the remote of 100% yet the signal indicator is red on the remote when the remote is 20 feet from the router. Several devices in the vicinity work fine.

If I walk within 5 feet of the router it works fine.

Is any work being done on the network stack? If not, I'll stop upgrading nightlies every morning to see if there are any changes!

Thanks!

CardinalFang
2007-10-17, 03:52
My Jive remote hasn't worked since r616. My router reports a signal to the remote of 100% yet the signal indicator is red on the remote when the remote is 20 feet from the router. Several devices in the vicinity work fine.

If I walk within 5 feet of the router it works fine.



I have the same problem with my BT Homehub router, although my laptop and Squeezebox consistently show good signal strength anywhere in the house.

It might explain some of the random behaviour I've seen recently. "Now playing" used to be rock solid, but now it doesn't update and if I use shuffle it loses all track of what's playing. Could this be down to loss of signal? it very rarely registers one bar in my home!

Skunk
2007-10-17, 05:34
"Now playing" used to be rock solid, but now it doesn't update and if I use shuffle it loses all track of what's playing. Could this be down to loss of signal? it very rarely registers one bar in my home!

I doubt it because I was having the same problems but it's fixed in r704 AFAICT.

CardinalFang
2007-10-17, 07:32
I doubt it because I was having the same problems but it's fixed in r704 AFAICT.

If only I could get the software update to work! I'll keep persevering.