Bugzilla – Bug 10774
SBC will reboot when coming out of 'sleep' state
Last modified: 2009-09-08 09:25:33 UTC
bug 10296, comment #26 QA confirmed r3789 will cause SBC to error then reboot when comming out of settings > advanced > turn off > sleep
Created attachment 4676 [details] 7.3r3476 firmware loaded Please try 7.3 r3856, as I am not able to reproduce with that version. I did see the reboot from sleep 1 out of 3 tries with 7.3 r3476 - while connected to SqueezeNetwork. The attached log does not have the error in it, unfortunately I did not activate my log capture at the time of the error.
OK, just reproduced this with r3856 while connected to prod.SN See attached log: look around this entry point ----- 134246:7664832 INFO (SlimDiscoveryApplet.lua:422) - serverDisconnected SlimServer {DEvans-MacBook.local} Unable to handle kernel paging request at virtual address 63616672 ----- I'll retest while attached to SqueezeCenter
Created attachment 4686 [details] Error Log
(In reply to comment #2) > OK, just reproduced this with r3856 while connected to prod.SN > correction, this log is from when I was connected to SqueezeCenter 7.3.2 r24695
Would anyone having this issue please try out SC 7.3.3, it will include a new Jive Firmware which should hopefully address this issue. Please visit http://downloads.slimdevices.com/nightly/latest/7.3/ then download build 24731 or later. Report back to this bug if you still see the issue. Include the steps to reproduce the error, what the controller was doing before the reboot. Were you connected to SqueezeCenter or SqueezeNetwork What player was your SBC controlling Did you have Audio Playback enabled at the time of the reboot Did you have Audio Playback enabled or disabled at any time Provide a map of your network topology. I.E. router/hub/switch, make/model/revision Thank you
Created attachment 4702 [details] controller log at reboot from sleep Here you have a log when my controller came out if sleep and rebooted. time for reboot is circa 7.44 24 january: circumstances left controller on it's back on a table , turned off SC server went to sleep, started SC server , surfed the forum a bit 5 minutes. went and picked up the controller = reboot . Audio playback is enabled This is with 7.4 3822 as there are no 3856 for 7.4 yet
We are having difficulty recreating the remaining reboot problems. James has found that at least one Controller he has for testing reboots due to a hardware (or device driver) fault. He is sending this to me for further investigation. So the remaining reboots I think are caused by one of: 1) hardware fault 2) application crash 3) watchdog timer problem To help diagnose this further I have created a special firmware that is avilable at http://eng.slimdevices.com/~richard/jive_7.3_r3952.bin. Put this firmware on an SD card, then upgrade from the Settings > Advanced > Software Update menu. Please also capture the logs on the SD card. With this firmware I think you'll see one of: 1) it still reboots, this may be a hardware fault. 2) it stops working, but does not crash. this is probably an application bug. 3) it keeps working, this is probably a watchdog timer problem. Please report what you see and post any logs you capture. Thanks, Richard
Mikael: Have you had a chance to try the new firmware?
No ,have not tried yet. I'm not at home, I'm working away from home right now. I can test maybe next week ?
Tested the special fw a little bit this weekend... And nothing ? it did not reboot hang or did anything unusual, maybe it was a bit slow on rendering artwork at some instance and on one instance the play and repeat symbol was missing for a short while. Other wise it seems to work just as good as the standard 7.4 fw . But no reboot's, I have to test more, i keep this fw for a while. I'm gone away on work again so maybe i'll test more next weekend.
We are still investigating this issue, we need to see log files from anyone experiencing the issue of Reboot from Sleep/Suspend. Please upload a log file from your SBC when this error has occurred. Insure you are using firmware version 7.3 r3993. Instructions on how to capture a log file can be found here: http://wiki.slimdevices.com/index.php/Squeezebox_Controller_Messages_File
Jon: please make a log and attach to this bug.
I am adding myself, after much posting on bug 10296.
Hello folks... Well, I received the replacement Controller you folks sent me. It started up, I connected it to my network, it upgraded itself to firmware r3993, everything looked ok. Then I turn it off, then turned it back on. Then I told it to "Sleep"... and guess what? It rebooted itself again, as my old one did. Could this possibly be connected to my network settings? I'm using WPA2 Personal on a hidden 802.11g-only network. - Tim
Oh, and remember - this isn't a reboot when it is coming OUT of a sleep state, it is a reboot when it is going INTO a sleep state. Is that a separate bug id, or part of this? Perhaps it should be "SBC will reboot when comming out of or going into 'sleep' state "?? - Tim
I am now using firmware 7.3 r3993, but ALL my three different SBC spontaneous reboot problems are still present regardless which of my two SBCs I use: 1) Every time the SBC tries to go to sleep, it reboots instead - this happens after about an hour of idle time. 2) When I command the SBC to go into sleep mode (by activating the /Settings/Advanced/Turn Off/Sleep function), it reboots instead. 3) When the SC/SBR/SBC system has finished playing a playlist (and the screen is still dimmed to black), the SBC reboots spontaneously And like for Tim, this happens when the controller goes into sleep, not when it comes out of sleep. Just like Tim, I am also using WPA2, and I am using a fairly long key.
Re my comment #16: "1) Every time the SBC tries to go to sleep, it reboots instead - this happens after about an hour of idle time.": The spontaneous reboot in this "idle timeout" scenario only happens if the SBC is not placed in the cradle, but instead left to itself, e.g. on a table, and only if it is left quitly, so that its screen has dimmed to black.
Hey all - where've the devs gone on this?
james: any news?
Dean: I'm waiting to get returned units from the customers, I am continuing to investigate this issue.
Created attachment 4810 [details] log of reboot during failure to start squeezeplay I managed to do the following, just to see what it would do ? my SC is latest 7.4 and SBC is 7.3r3993 . I know that headphone playback on my SBC will not work if not restarted after server is up. but for some reason I could still see the "controller" player in the"choose player" menu, after the latest upgrade (SC had been down without restarting SBC ). SBC did not react on insertion of headphone . So i chooses "controller" and choose a tune and tries to start it, then it freezes and showed the logitech logo, rebooting again... Provided the log fyi.
Everyone seeing this issue, would you mind answering a few quick questions ======================================================= *What version of SqueezeCenter are you running, please include the Build Number. Go to Settings > Status. Cut and Paste the SqueezeCenter and Player Information sections to this bug *What is the brand of your Network Router *What is the Model number *What is the firmware revision in the router *What type of encryption (if any) is enabled *Are your SB Receivers connecting to the network Wireless or are they Wired to your Router (or a hub then to the router) *What other devices do you have attaching to your network *What is the system hardware you have SqueezeCenter running on. Make, Model, CPU, Memory, Operating system, as much info as you can give me *When you saw this error, were you connected to SqueezeCenter or SqueezeNetwork
Info as requested: SqueezeCenter: Version: 7.4 - 24959 @ Wed Feb 11 01:00:42 PST 2009 Hostname: hal.home.lan Server IP Address: 192.168.1.5 Server HTTP Port Number: 9000 Operating system: Red Hat - EN - utf8 Platform Architecture: i686-linux Perl Version: 5.8.8 - i686-linux-thread-multi MySQL Version: 4.1.20 Total Players Recognized: 3 Library Statistics Total Tracks: 17,614 Total Albums: 1,384 Total Artists: 711 Total Genres: 140 Total Playing Time: 1391:43:20 Player Information Information on all identified devices connected to SqueezeCenter controller Player Model: squeezeplay Player IP Address: 192.168.1.6 Player MAC Address: 00:04:20:1a:37:ea kök Player Model: receiver Firmware: 59 Player IP Address: 192.168.1.3 Player MAC Address: 00:04:20:16:3f:16 Wireless Signal Strength: 99% vardagsrum Player Model: squeezebox3 Firmware: 124 Player IP Address: 192.168.1.2 Player MAC Address: 00:04:20:06:42:42 Wireless Signal Strength: 84% Controller fw 7.3r3993 Router: Linksys WRT54GL with Tomato 1.19 firmware WPA2 Personal AES Static IP no DCHP active My SB products are wireless SB3,SBR,SBC Otherwise there is a wired SC server and a wired desktop PC My server is a home made mini ITX machine: VIA EPIA-EN12000EG,EDEN V4/1200Mhz,SATA, Mini-ITX, DDR2-533, Fanless,LAN,Firewire Morex Venus chassi with powersuply WD1000FYPS hard drive for the music Samsung SSD drive for the OS. Hardware info from the servers system info. Hardware Information Processors 1 Model VIA Esther processor 1200MHz @ 37°C CPU Speed 1.2 GHz Cache Size 128.00 KB System Bogomips 2395.97 PCI Devices - Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter - FireWire - (5x) Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge - Host bridge: VIA Technologies, Inc. PT890 Host Bridge - IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller - IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE - ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] - Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller - PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge - USB Controller: VIA Technologies, Inc. USB 2.0 - (3x) USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller - VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP IDE Devices - hdb: TSSTcorpDVD-ROM SH-D162D - hda: MC8GE08G5MPP (Capacity: 7.46 GB) SCSI Devices - ATA WDC WD1000FYPS-0 (Direct-Access) USB Devices none Memory Usage Type Percent Capacity Free Used Size Physical Memory 52% 454.69 MB 492.86 MB 947.55 MB - Kernel + applications 29% 275.80 MB - Buffers 3% 32.24 MB - Cached 20% 184.81 MB Disk Swap 0% 895.99 MB 0.00 KB 895.99 MB Mounted Filesystems Mount Type Partition Percent Capacity Free Used Size /boot ext2 /dev/hda1 4% 91.15 MB 4.05 MB 100.30 MB / ext2 /dev/mapper/VolGroup00-LogVol00 18% 4.86 GB 1.15 GB 6.33 GB /mnt/music1 ext3 /dev/sda1 48% 427.65 GB 442.67 GB 916.89 GB Totals : 48% 432.60 GB 443.83 GB 923.33 GB OS: ClarkConnect Community Edition 4.2 . Btw I have the right memory type for this Mobo, it is a common user error with VIA motherboards to use the "wrong" memory, they are picky. Error has been seen with SqueezeCenter.
Everyone seeing this error, Please test the following, to see if the behavior changes: on the SBC to to Settings > Screen > Screen Dimming > set to Never ----------- Settings > Screen > Screensavers > Set the Screensavers to the following: When Playing > Now Playing When Stopped > none Delay > 30 seconds ----------- Settings > Advanced > Factory Test > Power Management > Sleep Timeout > set to 60 Suspend Timeout > set to 600 ---------- Use the controller as you nominally would. Report back here if you still see the reboot before / during / after the sleep or suspend event. Report if the controller was attached to SqueezeNetwork or SqueezeCenter. In this test; * sleep will be after 60 seconds (1 minute) of no physical activity with the controller. I.E. setting it down and not touching any buttons - the screen will blank out - controller will not suspend Should wake up when button pressed or picked up or shaken * suspend will be after 600 seconds (10 minutes) of no physical activity with the controller. I.E. setting it down and not touching any buttons - the controller will suspend all activity
I done the settings as suggested but don't have this problem anymore so i'm not the best guinea pig for this. I did however see what i explianed in my last post rebooting while activating squeezeplay under some circumstances. But i'm hanging on here for a while and see if it returns. forgot one router detail my SSID is not hidden (proven pointless and lees secure ? )
Created attachment 4816 [details] another log a reboot with squeezplay
James... I tried the above, and the device *seemed* to sleep the 1st time I tried it, tho' I was not timing it; also, all that really happened was that the screen blanked; when I shook the device, the screen came on instantly... seemed more just like the screen going off than a real sleep mode. When I did this test a 2nd time, timing it, more than 3 minutes went by and it didn't go to sleep, so I stopped my test. When I *told* the device to sleep, however, as mentioned, it rebooted as it had been. However, I didn't test it to see if the reboot happened upon sleep or upon presumed wake (i.e. shaking it, for example). I will try that later. - Tim
Ok, I put the unit to sleep and didn't touch it; it "went to sleep" and then rebooted, without my having picked it up or moved it or anything. So the problem persists. - Tim
Info as requested in Comment #22: My network router: NetGear WPN824v2 HW version V2H1 FW version V2.0.20_1.2.17 Config: Disabled SSID broadcast Disabled “Advanced 108 Mbps” Enabled “eXtended Range features (X2)” Mode: g and b WPA-PSK (TKIP) + WPA2-SK (AES) Region: Europe DHCP: MAC-based "static" IP addresses assigned via DHCP to all SB devices as well as the SqueezeCenter PC My SB setup: Duet #1: - Note: This is the SB being used 98% of the time, so this is the one I typically see the reboot problems on. - SB Receiver (FW 58): connected wired - SB Controller (FW 7.3 r3993) Duet #2: - SB Receiver: connected wireless - SB Controller SqueezeCenter setup: - SC version 7.3.2 - 24695 @ Mon Jan 19 18:55:04 PST 2009 - Installed on a 3 year old laptop: HP Pavilion ze2000 AMD Turion 64 Mobile, ML-30, 1.60GHz, 1.87 GB RAM Windows XP Home Edition version 2002 SP3 - Music files placed on separate 250 GB HD attached via USB2. The laptop is also used for general PC purposes while it is doing SC duty – however, I have seen no correlation of other PC tasks with the SBC reboot problems. On my wireless network I don’t have any other devices attached. On the wired network I have also attached: a Kiss DP-1500 – but typically not in use after I got my SB Duets a Maxtor Shared Storage II (MSSII) NAS – but that has been turned off I have only seen the SB reboot problems when the SBC was connected to the SqueezeCenter. However, the SB is almost never attached to the SqueezeNetwork, so I cannot rule out that the problem also exist in that scenario.
(In reply to comment #29) > My network router: > NetGear WPN824v2 See bug 9552
Thanks for the pointer. - But the original problem described in bug 9552 identifies the “Advanced 108 Mbps features” as the culprit, and I have disabled that. - The latest two comments (5+6) for bug 9552 say that the SBC r3993 cannot connect at all using NetGear WPN824v1 and WPN 824v3, but my SBC usually connects fine (occasionally it takes some time) using WPN824v2, so I am not sure it is the same problem. In http://wiki.slimdevices.com/index.php/RouterStatus, NetGear WPN824 is listed as being OK, if just the “Advanced 108Mbps Features” are disabled (which I have): > WPN824 V2.0.15_1.0.11 ? SB3 28 > SB2 works fine however if you have a SB3 you must go to the > router's "Advanced Wireless Settings" screen and check the > "Disable Advanced 108Mbps Features" > Note: This helps SB classic but not Controller. > box or songs are choppy I checked and found that there was new firmware V2.0.26_1.2.17 available for the NetGear WPN824v2 router, so I installed this, and tried it out again, but the SBC reboots are still present. But most importantly, bug 9552 still does not explain why the SB Controller should reboot upon entering Suspend mode.
In response to Comment #24: When I first tried to test this a few days ago, I basically got the same result as Tim in his Comment #27, i.e. that only the SBC screen went to sleep, but the SBC never went into “suspend mode” (and consequently never rebooted either). However, a menu-command (/ Settings / Advanced / Turn off / Sleep) to put the SBC to sleep still resulted in a reboot. I then tried to test it again today, with somewhat more reasonable results. => I cannot explain the difference – something strange is going on here! Test config (as requested in Comment #24): - Screen dim = never - Screen saver when playing = Now playing - Screen saver when stopped = none - Screen saver delay = 30s - Sleep timeout = 60s - Suspend timeout = 600s SC version 7.3.2 - 24695 @ Mon Jan 19 18:55:04 PST 2009 SBC FW r3993 SBR FW 58 Test #1: When I played a single track: 1) After a short while the “now playing” screen kicked in 2) After about 1 minute, the screen went black (=”sleep mode”) 3) After about 10 minutes (when it was supposed to go into “suspend mode”) the SBC rebooted. Test #2: When I just left the SBC (without playing any tracks): 1) After about 1 minute, the screen went black (=”sleep mode”) 2) After about 10 minutes (when it was supposed to go into “suspend mode”) the SBC rebooted. Test #3: When I commanded the SBC to go to sleep (/ Settings / Advanced / Turn off / Sleep), it rebooted instead. So, it appears that the changed configuration makes no difference for the SBC reboots – the SBC still consistently reboots whenever it attempts to go into “suspend mode”, or when giving it a menu-command to go to sleep. Note: I also used to consistently see reboots after the SBC finished “playing” a playlist, but this has not happened for some days now.
For anyone who's interested to know, James and I did some tests, and found that it *appears* that wpa_supplicant (or something else related to WPA2 usage) doesn't want to allow the Controller to go into a sleep state. So... the Controller starts to sleep, can't sleep, and then the Watchdog timer forces a reboot because it perceives there may be something wrong with the device if it can't sleep. Anyway, that's what appeared to be going on. Hopefully, the devs will come up with a test firmware to check out this theory. - Tim
Created attachment 4837 [details] Controller log SSID broadcast disabled, WPA or WPA2 auto enabled, DHCP address reserved for SC PC, Controller, and Receiver, Dlink DIR 655. Settings - Advanced - Power off - Sleep, wait 30 seconds, Controller reboots.
Aww James, now we're just "normal" and no longer "critical" *weeps* :-) - Tim
Tim, can you please try removing the DHCP reservation for your Controller and Receiver, and then try to reproduce this?
Do you mean, use a static ip? Or just remove the reservation and let router assign whatever ip it likes? - Tim
I really don't understand how the other controller bug is marked as resolved, and this one is now just normal, but yet between the two there are still tons of people like me that can no longer leave their remote outside of the cradle for a day because it is unable to do any power saving.
Ross... Okay, I let the router assign a non-reserved IP to the Controller, and amazingly... this time when I put it to sleep, it went to sleep! Hooray! So... do you know why IP reservation would cause this? - Tim
(In reply to comment #37) > Do you mean, use a static ip? Or just remove the reservation and let router > assign whatever ip it likes? > > - Tim Tim: yes, let the router assign the IP address
(In reply to comment #39) > Ross... > > Okay, I let the router assign a non-reserved IP to the Controller, and > amazingly... this time when I put it to sleep, it went to sleep! Hooray! > John, and everyone else having this issue, can you please try the above and let us know if this changes the behavior.
Sure enough, once I removed the reserved address from my DHCP server it now sleeps and wakes just fine.
With reference to Comment #41, I cleared out all reserved IP addresses on my router. I then commanded the SBC to go to sleep --- and lo and behold, now it actually went to sleep (actually “suspend mode” – the “sleep” menu command must be a misnomer) without rebooting. I was able to wake it again by picking up the SBC. But I have two main issues with this: 1 - First, HOW can the reserved IP address configuration on the completely separate router influence the operation of the SBC at all??? …What HAVE you developers been doing??? I checked the IP addresses after I cleared the IP address reservations from the router, and all devices still had the same IP addresses as they had when these were reserved. So what has actually changed? 2 - Second, I configured these reserved IP addresses in the router for a VERY good reason: For some reason, some or all of the SBC Duet entities seem to cache the last known IP addresses of its communicating peers. So when the Squeezecenter PC and SBCs have been powered off and then turned on again (I typically only have these turned on in the evening), then the entities are often assigned different IP addresses, and then the SBC cannot find them! I have now tried this out, by power cycling all of the SqueezeCenter PC, the SBC and the SBR, and sure enough, now the SBC cannot connect! It reports “Problem Connecting” and “Could not connect <SBR> to <SqueezeCenter PC>”, but what really seems to happen is that the SBC cannot connect to the SqueezeCenter PC, because while trying to connect, it says “Connecting to <SqueezeCenter PC>”. I tried to press “Try again” several times, but to no avail. I then backed out to the root menu, and it now just shows a very brief 3-entry menu. I then tried to select music source again, and now it seemed to accept the selection (at least it did not say “try again”), but it still only shows the very brief 3-entry menu (no music library, etc.), so I still can’t use the SBC. I then rebooted the SBC, and now finally I got the entire menu back, and the SBC is finally back in operation. This sounds bad – indeed it is bad – but occasionally this situation can get even worse, and I have had to reset the SBC and/or the SBR to get back into operation. All these IP connectivity problems do not exist when I configure reserved IP addresses in the router DHCP. So, this really puts me into a situation where I have to choose between having Plague or Cholera! And if I have to choose, I will still choose to use reserved IP addresses and live with the SBC reboots a while longer, rather than go through a prolonged system restart hazzle every day. (Unless I finally decide to fall back the SC software to 7.2.1 which was stable) Therefore I really hope you developers can find a proper solution to the SBC reboot problem, because I can’t live with dynamic IP addresses as a work-around. The alternative is ofcourse that you find a solution to the IP caching problem I described above.
I don't know if there's any connection, but now Fast Forward and Rewind no longer work from the controller. They work on my SB3 when I use the regular remote, but when I hold down FF/REW on the controller, nothing happens... it used to pop up a FF/REW screen on the controller, but no longer does. I'll need to do some more checking about this - anyone having this problem with the lastest firmwares and SqueezeCenter? - Tim
John, I am with you, I don't understand how my router reserving a DHCP address can cause the lockup, but it seems that this is for sure the "workaround" I also agree that its going to probably cause me connectivity issues since I also set up all the reserved addresses to rectify IP address conflicts.
Could the song scanner (FFWD/REW) problem be bug_10763? Did you reboot?
Marc... Reboot which? The Controller, the SB3, or my server? I shall use the info in bug 10763 to see if I can get around this as folks have described. I'll add any further comments about it over there. Thanks! - Tim
Regarding the problems I describe in my Comment #43 and Jon’s Comment #45: After I came home from work today, and started up my SqueezeCenter PC and my Controller (the Receivers were not rebooted), I had serious problems getting the system to connect. The Controller refused to connect to my Receiver #1, but I could actually connect to my Receiver #2. After many different attempts, the Controller finally connected after I power-cycle Receiver #1. So now I have had it! This is a %*¤&§# nuisance! So I have now configured my router back to using reserved addresses. => Now I again have the spontaneous Controller reboot problems! ...The lesser of two evils! ========================================================== However, I fail to see that deleting reserved IP addresses can be called a work-around for this Bug 10774, when establishing these very reserved IP addresses were necessary as a workaround for another much older bug that has never been fixed! Hence I also fail to see the rationale for reducing the priority of this Bug 10774 to “normal”. ==========================================================
There is another new firmware we would like everyone to try, please upgrade your controller (if it hasn't already) to firmware version; 7.4: 4824 7.3: 4673 After the upgrade, please factory reset SBC and SBR and attach them to your networks again. Post in this bug if these version are better or worse then 3993
James... Where do we get these firmwares from? - Tim
Tim, install either 7.4 or 7.3 nightly build from here: http://www.slimdevices.com/downloads/nightly Controller firmware will be downloaded automatically when SC is started. Controller should show that an update is available once it's fully downloaded.
Ok, same procedure as always; I thought we might be downloading it directly without just upgrading the server. Anyway - I did all as requested - new server version, updated firmware, reset to factory defaults, etc. The SBC still behaves as before; you put it to sleep, it reboots. This happens as was discovered before, when we use DHCP reservation for the controller on the router. When I turn off DHCP reservation for the controller, it works again. Is that all you needed tested? What what discovered that might be causing this? - Tim
It still reboots, now i did not do a factory reset, my settings works very well in other aspects so i won't touch before there is a compelling argument for me to do so. I think it's actually reboots more often now. I use fixed ip's with no DHCP present in the network btw, if one looks at files concerning network in the SBC my controller seems not to invoke any dchp services at all.
Observation: After a spontaneous reboot SBC no longer responded to SSH or PING but continued to *apparently* work ? SSH and PING resumed to work after a real reboot. I have simple network so no ill effect was observed, but are there some processes crashing in the background while this happens ? maybe important to others who experiences other problems ? Is it a good practice to do a manual reboot after one observes a "spontaneous reboot" ?
We are very nearly done with a solution for this bug, thank you all for your time and efforts as well as the many helpful posts. I'll post in this bug just as soon as we have a version for you all to test with.
Changing bug dependency, we are waiting on a back-port from another build to fix this one in 7.3.3. As soon as a new build is available that can be tested, I'll post in the bug.
7.3.3 has a new firmware that is being pushed out this weekend, look for r5149. Please re-test this version to verify it fixes the reboot on sleep with static DHCP address issue. If you are not running 7.3.3 please install it, the new firmware will be auto-pushed to you. If you are running 7.3.3 please re-start your server to get the new firmware.
With r5051, I had a reboot coming out of sleep, but alas forgot to make a log folder...
Hey, why was this marked "Resolved Fixed" if at least one person here reports that it didn't fix it? I will try it soon and report back myself. - Tim
Mickey: this one needs to be re-tested and added to the list.
7.3 r5225 is going to be pushed out, please RE-TEST with that version.
Fixed in 7.3.3 - r5225. If you've experienced this bug please update to latest nightly 7.3.3 build. Install the new version of SqueezeCenter, update your Duet firmware, factory reset both Controller and Receiver and setup one more time. Please post here in the bug with your findings. 7.3.3 nightly download here: http://downloads.slimdevices.com/nightly/?ver=7.3
I updated to April 8th's nightly 7.3.3, the latest firmware on the controller. I didn't do a factory reset of any device, however. I then switched back to using a reserved address for the controller, and put the controller to sleep. This time, it did not reboot. Hoorah hoorah hoorah! :-) It appears to be fixed. Would anyone mind revealing the technical details of the fix? I'd find it most interesting! - Tim
Tim, sure. We did a couple of things, one was to update the version of busybox we use. This got a number of DHCP fixes, and is probably what cured this bug. The other was to change from mini_fo to unionfs for a filesystem overlay in the kernel. This fixed an occasional kernel crasher. Together these seem to have had a magic effect :)
Verified fix in SC 7.3.3 r25948 Controller r2552 I am not able to reproduce this problem with the version stated above. Verifying fix for now. If anyone sees this issue please re open the bug.
It seems to be fixed for me as well - Thanks!
And it seems to (finally) be fixed for me too. Tough ride, but we got there...:-)
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.