Bugzilla – Bug 3301
Playlist Setup shows URL instead of Playlist Name
Last modified: 2008-12-15 13:07:29 UTC
I have configured an alarm to play every morning at 7:30. When the time is met, the SqueezeBox says "Now Playing <alarm playlist>", but it doesn't play anything. The current playlist becomes empty. I can manually play the playlist, so there doesn't seem to be a problem with the actual music files. It looks like it is simply having trouble loading songs to the current playlist after it has cleared it. I can't see any errors in the log.
d_source, d_command may help on this. the alarm issues a "playlist playtracks playlist=<id>" command when triggered.
I just tried this again with the latest 6.5b1, and it's now working. One minor issue though - if I use the web interface to set an alarm, I see several warnings when saving the prefs that the volume isn't a valid value (0-100), and the fields are submitted as blank.
Web interface seems ok to me. I'm not getting any warnings and volume setting seems to work. I didn't notice until now that the pulldowns have changed to react onChange instead of on submit, however.
I think maybe my preference file had blanks instead of valid values for the alarm volumes. I've just revisited the alarm settings page after submitting changes last night, and all volumes that were previously blank are now set at 50. The warnings do not appear when submitting changes now. If I attempt to change a volume to blank, I get slightly different error text: New value for Alarm Volume (0-100) 7rejected: Invalid value specified: I think "7" above refers to the alarm section (7 being sunday). It's a minor thing, but the alarm name should be used in error/warning messages instead.
I'd suggest rewriting the summary to reflect what you want in the end. changing the setting message will be non-trivial, however, as the setup code doesn't allow for custom message, since it expects only a single string token.
added a fix to show the alarm day name when responding to settings changes at change 7203. Wtih setup being rewritten, I decided to go with the simplest path instead of the complete one. Array prefs that make use of the changeIntro will have to provide the full string, rather than a token. This of course means they fall behind after a language change.
The original problem of not playing music when the alarm fired went away with an update to 6.5b1. So I have updated summary to make this bug track the trivial bug where an error message reported when attempting to save alarm settings on web UI wasn't particularly meaningful.
Try to update the Summary again after a mid-air collision!
I can't update the summary - bugzilla complains.
I'm updated the setting cvhange response, check the April 29 nightly.
Phil - is this still an issue with the latest 6.5? Thanks
I am not seeing any errors now when saving changes to the alarms. When I enter a monday alarm (select a playlist and save the alarm), the web UI responds with: Alarm Monday: 1 Alarm Playlist Monday: file:///M:/Music/SlimServer%20Playlists/Alarm.m3u Set Alarm Time Every Day: 23:40 1) Shouldn't it report the playlist name, not URL? 2) I didn't change anything for the every day alarm, but it reports that the time was changed. Pretty minor observations though.
kdf - any thoughts here? I think you're the most familar with the Alarm code.
well, the Monday/Every Day stuff wont' exist any more, as that was buggering up the checkbox selection. The url is all you'll get without futzing with the setup code, and that kind of post-process falls into postChange nether regions. I wouldn't want to touch any of that (save for maybe simply reporting "xxx changed" and dump the actual info, as it really should be obvious what it changed to). Never able to reproduce a case of a message of something that wasn't changed. I susspect either it was changed accidentally, or more likely the pref is corrupt in some way, preventing the current value from being properly incorporated. Server doesn't make it easy to go between scalar and array prefs, which is what happened when the alarms went multi day. I would recommend this be punted forward until the setup code rework can be fit in.
Right - Setup refactor is post 6.5
Phil - is this still an issue?
When saving changes, the web UI now only reports "The changes have been saved", rather than try to list the changes that were saved. Therefore it isn't wrong any more, or if it is, I can't tell ;-)
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.