Bugzilla – Bug 8250
TP loses slimproto connection if sent compressed grfe frames for both screens
Last modified: 2009-07-29 13:59:57 UTC
Using the Extended Text Display for the Visualizer Screen will freeze the Transporter while using SqueezeNetwork direct once switched to now playing. Transporter will eventually recover after a period of time. I did not see this behavior while using SqueezeCenter including using SqueezeNetwork sourced audio.
Easily reproduced. TP locks up and disconnects/reconnects to the server after about 30 seconds. While locked, TP still sends button/knob events. Tested both firmware 37 and 42, probably not a firmware bug. Triode: any hints on where to look for this? There is no debug or crash output when it locks up.
Looks to me that it work with softsqueeze but not a real transporter on the production SN server. On the real transporter, it seems to be the push into Now Playing which kills it - this will create a grfe slimproto frame which is larger than one TCP packet as it contains both screens. Can we turn on slimproto debug to see what is being sent in each case? Is there anything different in the slimproto implementation for SN?
grfe frames on SN are also compressed, might be related to that.
This behavior is still in the current version of SqueezeNetwork. Changing target to Devo. Please change target if not appropriate.
Thsi is potentially a firmware problem as it works with SoftSqueeze on SN. I think its something to do with the compress screen updates when they cover both screens.
Yeah, I will probably see about disabling compression when the frame contains data for both screens.
I disabled compression for screen 2, but it didn't fix it. Disabling compression on both screens did fix the issue, so I think I'll just take the easy fix of disabling compression for TP until we can fix the firmware bug.
Workaround in 7.1 change 22826. Leaving this bug open for the real fix.
Punting to next release.