Bugzilla – Bug 8793
Sleep at end of song not accurate if you pause/seek/etc
Last modified: 2009-09-08 09:29:07 UTC
If a song is playing and you hold the snooze button to select Snooze at end of song, and then FFWD the track, two oddities occur at the end of the track: 1) the progress meter retreats from 100% filled, to about 90% filled, making it appear that the track is unfinished. 2) there is a marked delay before snooze actually occurs, perhaps proportional to the length the track was advanced. Playback is complete, but the unit sits idle. It seems like advancing perhaps does not recalculate the time until snooze.
snooze simply sets a timer based on how long is left. It's not an active feedback system, so yes it's proportional to the amount you skipped. The whole snooze system would need to be rewritten, perhaps using a target time and checking ever second for a match. Overkill imo.
I figured it was a fire-n-forget. A per-second check does seem overkill. Perhaps instead a playback changing event can cause a re-calculation of the queued event fire time. No matter; I saw the glitch and so figured I'd report it.
perhaps, "sleep at end" could simply cause a subscription trigger to call back for an instant snooze at the next track change event. it's a special case, so a bit of a nuisance, but probably less than getting into a "checklist" of things to do at track change/button pressing events.
I'm inclined to won't-fix this one, as any solution would be an ugly hack. Dean: do you care?
So, if you sleep at end of song and you skip song, what do you expect it to do? Should it sleep at the end of the next song? Or sleep immediately?
Going to sleep immediately after you press Skip track would be a very disturbing behavior. I think conceptually, the usage case scenario is pretty straightforward, but probably not terribly comomon. You press snooze to snooze at the end of a long track, and decide you want to hear another track instead. In my mind, *snooze at end* has been set, and there is no intuitive notion about the mechanics of how alarms are implemented or that the snooze would be canceled. Similarly if you press snooze at end after starting a long track, and want to skip some front matter, I'm still believing the unit will go to sleep when playback has completed. On an abstract level, I'd debate Andy's comment about the fix being an ugly hack - rather, the ugliness is the presumption that an event is fixed in time from the moment the snooze button is pressed (vs. attached to a track end/change event). :-)
it's an ugly hack already. we should get rid of it. 15 minutes is 15 minutes. End of song leaves too much or interpretation. As it is, it's just a timer like the rest with a different time limit. Really, the more sensible thing is if you really want quiet after the current song, turn off repeat, get rid of the songs after it and set a sleep for after the track length. Trying to keep making automatic features that simply "do what I want now" is a diminishing return. As I said above, too many interpretations and too many wanting to suggest what it "should be doing" instead.
"No Snooze for you!" - The Snooze Nazi
Suggested workaround: after putting on the sleep timer, instead of peering at your Squeezebox, close your eyes and try to go to sleep.