This would be a nice addition -- it already does this in reverse when using the sleep timer (fade out after so many minutes).

pref was added at change 2534, but no UI was implemented at that time.  

I guess the first question is does this have to be a pref for every day, or just a global alarm pref?

I can't think of a reason why this would need to be a pref that was different for each day/alarm.

Would this behavior be the most desireable as a default setting?  At first consideration it seems to me that it would -- it should only take a few seconds to get to the proper volume.  Although on second though, it really is the purpose of an alarm to "jar the user awake" so maybe we don't want to sneak in by default and get some angry users who didn't wake up because of the nice smooth transition.

I'd propose modeling on the Bose clock radios, which I assume they researched quite well (mine sells for $500).  

For those, all alarms ramp up, and the ramp up speed is not variable.

While choice is good, it's not absolutely good. It seems to me most would probably either want ramp up or not; they wouldn't want to vary across alarms. I'd assert that the # of people who'd be annoyed having to set that for every alarm would outnumber those who'd like that ability. 

I'd be happy to provide a standard for how fast to ramp up (e.g. +1 in volume on 100 scale in 1 second), based on my Bose.  Of course some may find it too fast or slow, but gotta start somewhere.  I'll post it within a coupla days. 

Also, I can't imagine who *wouldn't* want ramp-up, but perhaps that's a failure of imagination. :)

"pref was added at change 2534, but no UI was implemented at that time"

does that mean that I can edit some text somewhere to register this preference?  Sorta like editing a registry entry or a prefs.txt file? (I'm handy with a PC but have no computer science/programming background).

look for slimserver.pref, edit the line with 'alarmfadeseconds'

that should work, but I have not tested.

*** Bug 2582 has been marked as a duplicate of this bug. ***

Created attachment 1019 [details]
possible ui

only tested the ui part, as I can't be bothered to set up and wait for an alarm while I have other stuff to do.  this is a basic ui, and should work.  it might need some string tweaking, tec.

Subject: Re:  Gradual volume ramping for Alarm function

I prefer to have a fixed fade-in rate (say 20 seconds) and be able to  
turn it on or off.  Entering numbers is bad.

patch works for me and I can verify that the fade-in works fine.  I set it to 20 seconds and it seemed nice.

kdf do you have an amazon wishlist?

Created attachment 1020 [details]
simple toggle

thaks Dean,  This is a simple toggle, using the [x] for enabled style in player UI.  No fancy animation, just changes the X.  Web ui is a toggle at the top of the alarm settings.

and as a matter of fact I do actually have a wishlist at amazon.ca (kevindf|at|shaw.ca) now that its mentioned (I'd forgotten).  Embarassingly out of date tho...I'll have to fix that ;)

committed a tweaked version of the second patch (a boolean pref as Dean requested) to the 6.5b1 trunk at change 5222.  Let me know if any changes are needed, or if this can be closed off if satisfactory.

Can someone point me in the right direction on how to implement this patch? Sorry to be such a noob, but I did invest a half hour trying to figure it out (I saved the file in the plug-in folder of both the player and the server, no luck...)  Also I've tried the beta but it seems to be hanging up on my computer. 

Mark, it's not a plugin.  It is a server patch, which can be used to alter sections of the server code.  if you are running the windows installer version, you won't have the option to patch, since this requires a compiled version of the server.  if you wish to try this out, a version is going to be in the Nov 17 nightly build of 6.5b1, but be aware that this is experimental and may introduce other temporary quirks.

Thank you for that explanation!

Hmm. My Thinkpad X40 doesn't seem to play well with the beta - I get the "SlimServer Starting" bubble, but it never actually starts. (I even left it on overnight).  Anly way for me to get that into 6.2.1 or help you debug what's going on with my machine? (Perhaps I need to submit a separate bug report? :)

Please ask these sort of questions on the forums.  The bug reports just get too cluttered otherwise, especially for those of us on the cc list!

Re: "these sorts of questions" - no problem. Last comment:

I tried editing the prefs file. I would change "alarmfadeseconds" from 0 to 20, and save using WordPad. But then, when I would use the web interface to set the alarm to test, it wouldn't fade up.  I subsequently looked at the prefs file and alarmfadeseconds had somehow been changed back to zero. It seemed as though setting the alarm in the player interface would also rewrite the alarmfadeseconds to zero. 

After a rewview by someone at SD the fixes from last night wil either go into 6.2.2 or be held for release as 6.5.  Editing the pref, should you choose to go with that as a workaround, must be done with the server OFF.  Otherwise, you will see them being overwritten.  There is nothing in the code that should change it, although the reading of the pref does assume that the pref is an array, which it is not.  I don't know what kinf od affect that has.  As with anything, some patience is required.

Let's get it into the trunk now.  Leave 6.2.2 for essential bug fixes, not new features.

ok.  as mentioned above, this is added in 6.5 change 5222.  It is already available in the 6.5 nightly builds.