Bug 15151 – Alarm results in display and buttons freeze (7.5)

Bug 15151 - Alarm results in display and buttons freeze (7.5)

Summary:

Alarm results in display and buttons freeze (7.5)

Status:	RESOLVED FIXED

Product:	SB Radio
Classification:	Unclassified
Component:	Buttons/Knob
Version:	Include FW version in comment
Platform:	PC Windows XP

Importance:	P1 normal with 4 votes (vote)
Target Milestone:	7.4.x
Assigned To:	Ben Klaas

URL:
Keywords:	radioAlarmsCritical

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2009-11-20 01:02 UTC by Simon Turner
Modified:	2009-12-23 07:50 UTC (History)
CC List:	4 users (show)

See Also:
Category:	---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Simon Turner 2009-11-20 01:02:56 UTC

When the alarm fires all the front panel buttons and knobs cease to work, with the exception of a long press of the back button.

Comment 1 Bill Burns 2009-11-30 08:57:37 UTC

I have the same problem on the latest 7.5 nightly, but I can get out of the freeze by pressing and holding the Alarm button.

Comment 2 Remy Bohmer 2009-12-06 12:19:08 UTC

(In reply to comment #0)
> When the alarm fires all the front panel buttons and knobs cease to work, with
> the exception of a long press of the back button.

Happens here only on the firmware distributed with 7.5 beta.
It works properly with r7915 on 7.4.1. It must be a regression since r7915

Remy

Comment 3 George Hines 2009-12-13 16:54:52 UTC

I have this problem on the latest 7.5 nightly release.

One additional note:  I can still use a remote control to control the Radio.  Once I press back on the remote, all of the buttons of the Radio start working again.  Just FYI.

Hope this bug is fixed soon...

Comment 4 Ben Klaas 2009-12-21 14:28:39 UTC

flagging critical bugs for SB Radio with keyword radioAlarmsCritical

Comment 5 Ben Klaas 2009-12-23 07:00:38 UTC

another data point: I can only reproduce this on a radio running 7.5 firmware, so my hunch is that the earlier statement about this being a regression is correct.

Comment 6 Ben Klaas 2009-12-23 07:20:52 UTC

smoking gun is in this debug...just looking for the proper fix now...

Dec 23 09:12:11 squeezeplay:    /usr/share/jive/jive/ui/SimpleMenu.lua:686: attempt to call method 'setPixelOffsetY' (a nil value)
Dec 23 09:12:11 squeezeplay: stack traceback:
Dec 23 09:12:11 squeezeplay:    /usr/share/jive/jive/ui/SimpleMenu.lua:686: in function 'setPixelOffsetY'
Dec 23 09:12:11 squeezeplay:    /usr/share/jive/jive/ui/Menu.lua:188: in function 'resetDragData'
Dec 23 09:12:11 squeezeplay:    /usr/share/jive/jive/ui/Menu.lua:382: in function '_eventHandler'
Dec 23 09:12:11 squeezeplay:    /usr/share/jive/jive/ui/Menu.lua:1053: in function 'callback'
Dec 23 09:12:11 squeezeplay:    /usr/share/jive/jive/ui/Widget.lua:656: in function </usr/share/jive/ji
Dec 23 09:12:11 squeezeplay: WARN   squeezeplay.ui.draw - jiveL_dispatch_event:762 error in event function:

Comment 7 SVN Bot 2009-12-23 07:50:57 UTC

 == Auto-comment from SVN commit #8259 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=8259 ==

Fixed Bug: 15151
Description: don't call setPixelOffsetY when it's a non-existent method of the object
this bug was caused because a group widget rather than a textarea was being used as a menu header widget