Bug 8383 - Alarm playlist needs to keep state -- shuffle and/or location in current playlist
: Alarm playlist needs to keep state -- shuffle and/or location in current play...
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Alarm
: 7.2
: PC Windows XP
: -- enhancement with 10 votes (vote)
: Future
Assigned To: Max Spicer
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 10:49 UTC by Caleb Crome
Modified: 2011-12-27 05:20 UTC (History)
7 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Caleb Crome 2008-06-11 10:49:10 UTC
Setup:
* I have a local music playlist set up as my alarm playlist.
* I rarely use shuffle during normal play, and normally have shuffle turned off.
* I use Squeezebox as my alarm.

Problem:
Since my playlist is from a local source (as opposed to pandora or internet radio), when the alarm goes off, it always starts at the beginning of my playlist.   This is kind of goofy, as I'm woken up to the same song every morning.  

What should happen is:
* If I don't have shuffle set on my playlist, the alarm should pick up at the next song in the playlist from where it was turned off last morning.
* If I do have shuffle set, well, it should switch to shuffle mode if not already in shuffle mode, and start playing.

The alarm playlist really needs to store (at least) 2 different bits of state:  shuffle mode, and index of next song to play.  

Currently, this is a per-player setting only, not per playlist.
Comment 1 KDF 2008-06-11 11:15:01 UTC
saved playlists already store currtrack, so playing should restore to that track.  However, alarms often don't last into the next track, so perhaps a jump(+1) command would do what you need.  This way, each time the alarm runs, it moves to the next track and starts playing.  Side-effect is that first time running, it won't play first track.  

I've also done an autoshuffle option in the plugin version that sets shuffle param when the alarm runs.  The plugin also jumps to next song after each snooze timer expiry.
Comment 2 Max Spicer 2008-06-11 13:58:32 UTC
Taking.  I'll look at what can be done about this as part of my rewrite.  I haven't yet done the bit that actually sounds an alarm (it just creates a message in the log file at the right time at present), so this is a good time to consider how it should work.
Comment 3 Chris Owens 2008-06-20 17:11:15 UTC
I'll go ahead and mark this for 7.2, so we will be reminded to check in from
time to time.   Thanks Max! 

--Note except Dean set it for 7.2 before me causing a bugzilla collision--
Comment 4 Max Spicer 2008-06-23 04:15:17 UTC
I don't think any specific work needs doing for the shuffle case.  If shuffle is enabled before the alarm sounds, it will still be enabled when the alarm starts to play.  May need to think about what random mix does to this, though.  Should shuffle be preserved after the alarm has played a random mix then been stopped?

For the current playlist, it simply does a play, which should resume playback where it was last left off.

The case that needs handling therefore is saved playlists.  At the moment, all urls are just sent through execute(['playlist', 'play'], $url).  This would need to be changed to detect if the url is a saved playlist and to jump to the currenttrack if it's defined.  The alarm should probably store the id/url (which one?) of the last played track, and do a jump if the track it's about to play is the same as that.

I don't know how to do the stuff in the last paragraph.  I'll need some help from someone that actually understands Squeezecenters playlists/tracks/urls.  ;-)
Comment 5 Caleb Crome 2008-06-24 14:20:59 UTC
The thing that needs to be preserved is 'alarm shuffle' as an independent variable from 'shuffle'.  Or perhaps 'playlist shuffle'.  I rarely use shuffle during normal play, so it'll be off.  However, when alarming, I may want shuffle.

Comment 6 Max Spicer 2008-06-24 14:30:47 UTC
So you're asking for an option to shuffle the playlist during an alarm as well?
Comment 7 Max Spicer 2008-07-26 01:56:53 UTC
I'm not at all sure where this bug should go.  I'm happy to do work on it, but don't know what that work should be.  Reassigning to get a decision.
Comment 8 Chris Owens 2008-07-28 10:57:45 UTC
So it sounds like some UI decisions need to get made on how to implement this.  Should the alarm menu contain the settings for whether to shuffle and/or position settings should be used?  Should that information be stored in the prefs?
Comment 9 Max Spicer 2008-09-11 05:22:51 UTC
*** Bug 9421 has been marked as a duplicate of this bug. ***
Comment 10 Jim McAtee 2008-09-11 21:01:23 UTC
(In reply to comment #0)

> The alarm playlist really needs to store (at least) 2 different bits of 
> state: shuffle mode, and index of next song to play.  

Shuffle mode for an alarm isn't a state.  It's either enabled for the alarm or it's disabled, according to a setting that needs to be configurable in the user interface.

Shuffle mode for a player is a state.  It would probably be more correct to restore it to the state it was in prior to beginning the alarm rather than just clearing it when exiting the alarm.

How about approaching this as two different requests?

#1 Add shuffle mode, restoring player shuffle state when the alarm ends.

#2 Save the current (next) track in a playlist used in an alarm.  The problem with this one is that many people aren't going to want this behavior, so it will need to be another option.
Comment 11 Kyle K. 2008-09-20 20:02:39 UTC
Why not just add one more preference to the Alarm Clock preference page?  I think it would go well right after the "Repeat" option for each alarm.  How about a simple, single select pull-down option box with the following options:

Shuffle:  None
          Album
          Artist
          Song

In the stored preference file (/etc/squeezecenter/server.conf on my Linux box), simply add one more preference for each alarm:

_shuffle: 0

Where:

0=None
1=Album
2=Artist
3=Song

(Or just use the text, which ever is easier)
Comment 12 Michael Herger 2008-11-11 00:40:00 UTC
*** Bug 9953 has been marked as a duplicate of this bug. ***
Comment 13 Chris Owens 2008-11-12 15:14:40 UTC
Not required for the 7.3 release.
Comment 14 Max Spicer 2008-12-08 00:24:46 UTC
*** Bug 10248 has been marked as a duplicate of this bug. ***
Comment 15 Ian Pallfreeman 2011-08-25 06:48:29 UTC
This bug is three years old!

I'm sure a large number of your customers have bought a Radio in the hope of doing exactly what is described here: set up a carefully chosen playlist to wake us in the morning, but have it shuffled, so we don't hear the same songs every day. And when it didn't work, felt very disappointed with their purchase.

In my humble opinion this is a little problem which has a disproportional  negative impact on the "user experience" and should be given a higher priority.

This copy has been sanitised. IRL, I'm swearing. At Management. As usual. :)
Comment 16 xavier.gouy 2011-12-27 05:20:33 UTC
Just got the Squeezebox Radio, and realy disapointed to realize that this quite simple function is not implemented.

When we bought a Squeezebox Radio / Boom / ... we USE the alarm function. And for a such expensive / techniclly advanced piece of hardware, its quite incredible this function's still missing.

Three years after... Hope you read it...