Bugzilla – Bug 13125
Home Menu settings bug
Last modified: 2011-01-14 12:11:02 UTC
r6838. I did a factory reset and then configured the Home Menu in Settings. While selecting items, I accidentally checked 'Squeezebox Name', then I immediately unchecked it. Going out to the Home menu, 'Squeezebox Name' was in the menu. Going back in to Settings > Home Menu, the item did not show a check. I checked it again, unchecked it again, and it now no longer appears on Home.
I have noticed this same behavior in other SP based products. Adding/Removing items to the home menu does not always work.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Created attachment 6121 [details] remove before rename I found a case where any changes are not kept for windows SqueezePlay. This is due to the states being written to *.new files and renamed to *.lua. On the arm-based systems, this probably works since POSIX will overwrite on a rename. Windows, however, fails if the file exists (errors are showing in the logs). This patch will add a few lines for win32 builds that removes the old files before trying to rename. Perhaps some debugging on the other architectures might show that this is a similar issue to what is causing lost settings on other players.
as a reference for this type of problem, and other solutions to consider: https://www.securecoding.cert.org/confluence/display/seccode/FIO10-C.+Take+care+when+using+the+rename()+function
Don't know if they're related, but the failure of settings to be saved in desktop SqueezePlay on Windows is discussed quite a bit in this forum thread: http://forums.slimdevices.com/showthread.php?t=67760 There are a number of other bugs with desktop SqueezePlay on Windows, the most significant being server connection problems, but it would be nice to see this fix implemented.
I think the connection problem is related. I was looking at this in a debug when the rename errors started showing up. Adjusting the home menu is the most easily repeatable trigger so I locked into that as the connection errors scroll past far too quickly. The SlimDiscovery.lua file also has this renaming issue and a .new version is created on startup. It might be the reason the connection doesn't complete. You'll find that SbS does see SP and will play, just that SP doesn't seem to realise it. Also, with this patch in place, my local build connects with no issues. I'm tempted to put this in regardless, as all seems so quiet I suspect many are taking time off after the Radio crunch.
== Auto-comment from SVN commit #7864 to the jive repo by kdf == == https://svn.slimdevices.com/jive?view=revision&revision=7864 == Bug: 13125 Description: for windows, delete old settings files before renaming. Win32 file system will fail a rename if the file exists, so this helps store home menu changes and also relieves connection issues due to failing to write SlimDiscovery.lua updates.