I hadn't noticed this bug, as our wakeup playlist actually starts with a song that fades in!

I think this one is pretty important; hope it makes 7.2.

Is this specific to boom or all players?  I admit I haven't really checked, nor really noticed as I still have the plugin doing the task on SB3 most mornings.  I wonder if it may have to do with the volume ramping on Boom as compared with older players. Since the low levels have been made lower, the ramp may no longer be heard properly.  Debug code could be added to Player::Player::fade_volume to actually track the ramping values.

I just tested it against boom and the duet.  Both did not fade in the alarm.

I tested this against Boom, SBR and SB3 and fade-in does not work for me either.

SqueezeCenter Version: 7.2 - 21946 / Mac OS X 10.5.4 (9E17)
Boom FW18
SBC FW101
SBR (didn't write that one down!  can get it if needed)

patch for debug.  Please try this.  I'm afraid I cannot as I'm flying east in a couple of hours and won't be back for 4 days (not to mention being loaded with project work so making time costs me so much more)

Index: Slim/Player/Player.pm
===================================================================
--- Slim/Player/Player.pm	(revision 22003)
+++ Slim/Player/Player.pm	(working copy)
@@ -338,7 +338,7 @@
 	my ($client, $fade, $callback, $callbackargs) = @_;
 
 	my $int = 0.05; # interval between volume updates
-
+warn "fade volume ".$client->name;
 	my $vol = abs($prefs->client($client)->get("volume"));
 	my $now = Time::HiRes::time();
 	
@@ -364,20 +364,20 @@
 	if ( $f->{'vol'} && $f->{'vol'} != $client->volume ) {
 		return;
 	}
-	
+	warn "no manual bypass";
 	my $now = Time::HiRes::time();
 
 	# new vol based on time since fade started to minise impact of timers firing late
 	$f->{'vol'} = $f->{'startVol'} + ($now - $f->{'startTime'}) * $f->{'rate'};
 
 	my $rate = $f->{'rate'};
-
+warn "fade rate ".$rate;
 	if (
 		   !$rate 
 		|| ( $rate < 0 && $f->{'vol'} < $f->{'endVol'} )
 		|| ( $rate > 0 && $f->{'vol'} > $f->{'endVol'} )
 	) {
-
+warn "done fading";
 		# reached end of fade - set final volume
 		$client->volume($f->{'endVol'}, 1);
 
@@ -396,7 +396,7 @@
 		}
 
 	} else {
-
+warn $f->{'vol'};
 		$client->volume($f->{'vol'}, 1);
 		Slim::Utils::Timers::setHighTimer($client, $now + $f->{'int'}, \&_fadeVolumeUpdate, $f);
 	}

[16:38:00.0199] Slim::Utils::Misc::msg (1358) Warning: [16:38:00.0198] fade volume McBoom! at C:/.../Slim/Player/Player.pm line 341.
[16:38:00.0206] Slim::Utils::Misc::msg (1358) Warning: [16:38:00.0204] no manual bypass at C:/.../Slim/Player/Player.pm line 367.
[16:38:00.0209] Slim::Utils::Misc::msg (1358) Warning: [16:38:00.0208] fade rate 2.75 at C:/.../Slim/Player/Player.pm line 374.
[16:38:00.0212] Slim::Utils::Misc::msg (1358) Warning: [16:38:00.0211] 0.00118541717529297 at C:/.../Slim/Player/Player.pm line 399.

I used Radio 4 as a playlist this morning and I'm sure I could detect it fading in.  It was very slight though, so maybe it is just that the fade is now happening far too quickly.  Of course, it could have just been due to my ears gradually coming online as part of the wakeup process...

Alarms are definitely fading in for me now.  Don't know what's changed.  Is anyone else still seeing them not fade in?

QA to see what the current behavior is.  Andy says this should be assigned to him if it's still not working.

Fade-in worked this morning.

Fading in for me as well.

Fade-in isn't working for me again as of 22374.

Fade in works when attached to SC/SN.  when the player is Disconnected, then the fade in alarm does not function properly. Bug#:8933

Are you able to reproduce the fade in error with the latest 7.2 and firmware?

Fade in worked correctly for me @22428 w/fw 23 when connected to SC.

Not fading in for me again.  I was on yesterday's build and firmware this morning though, 22405 and FW 22.

What's happening is that the alarm activates, then there's a 20-30 second period of silence (looks like it thinks it's fading in), then the music starts at full volume.

Strangely enough, one of my alarms this morning started at full volume after 5-6 seconds of silence, played for a second, another few seconds of silence, then playback for a few seconds, silence and constant playback.

Log attached.

Created attachment 3754 [details]
Log file

Created attachment 3755 [details]
Move fade_volume call to after playback is started

This is working for me, but I suspect it could be that fade_volume is sometimes cancelled by whatever happens when the alarm playlists are played (radio streams, random mix etc etc) - it would therefore be playlist dependent.  I'll try moving the call to fade_volume to after the call to start playback.  The attached patch does this but I don't want to check it in until I can test it on a real player - it's possible it could cause a volume spike before the fade starts.  Please test with the patch applied if you can.

I've committed that patch as change 22459.  It's hard to test as alarm fading worked for me anyway, but I've checked that they still work after the patch.  Fingers crossed...

Although this is listed as "resolved fixed", it's still not working for me as of 22504.  I get a long pause followed by full-volume playback.

I seem to be the only one this isn't working for though.

What's your alarm playlist?  It's quite possible that what's actually happening is that your alarm playlist is failing and it's falling back to 10 random songs.  There's another bug open for that - it's a problem with the protocol handling in squeezecenter.

I'll reopen this bug as alarms should really fade in, even after a fallback.  At the moment it's missing a call to fade_volume at the appropriate point.  Probably not worth fixing for 7.2 though.

Created attachment 3783 [details]
Add a call to fade_volume after playing fallback alarm sound

This patch is untested but should fade the volume after falling back to an alarm sound.  It's necessary because the previous fade_volume will probably have completed by the time the fall back sound is started.  No hurry for 7.2, as far as I'm concerned.

I'm simply using a random song playlist.  It does work (doesn't appear to be falling back) but I do get that long pause before it starts.

If you're using random songs it won't be working at present - see bug 9097.  However, the fall back when a playlist fails is to pick ten songs at random and play them (which is different to random mix).  This happens after 20 seconds, by which time the fade has finished.  My attached patch would make it do the fade in the fall-back situation as well.  Hopefully bug 9097 will be fixed for 7.2.

Well now that bug 9097 has been fixed (although it took to build 22808 to kick in for me) I no longer have the long pause when the alarm starts.

I think this is what was masking the fade-in.  I believe alarms are fading in properly now, although it's hard to tell when you're fast asleep and being woken up...

I still need to commit the attached patch to 7.2.1 to make fall-back playlist alarms fade in.  This bug should stay open until then.

Thanks for the input, Mark.

Unfortunately, I confirmed alarms are not fading in for me, at least not this morning.

I gave Boom a very good listen this morning and still no fade-in.  However the ~20 second pause is back.  I also noticed something odd filled the screen for 1/4 sec, looked like "Now Playing" - "Nothing", but I couldn't be sure, it went by too fast.

FW 32.  SC:

SqueezeCenter Version: 7.2 - 22915 @ Wed Aug 27 01:08:24 PDT 2008 - Debian - EN - utf8
Perl Version: 5.8.8 x86_64-linux-gnu-thread-multi
MySQL Version: 5.0.51a-3ubuntu5.1
Platform Architecture: x86_64-linux

Log attached.

Created attachment 3914 [details]
Log file 2

This covers three alarms this morning.  On the last one I listened for a bit and stopped it at the second track.

Mark, the issue here isn't that your alarm isn't fading in.  For some reason, your random song mix is failing.  The alarm is therefore falling back to random tracks after 20 seconds (this isn't the same as a random song mix).  At the moment, there is no fade when the fallback is triggered.  I'll fix that in 7.2.1.

So, why is your random song mix failing?  I have no idea, but please open another bug.  In that bug, could you also attach a log with plugin.randomplay logging set to Debug along with player.alarmclock?  Could you please also confirm that random song mix works when you trigger it from Music Library->Random Mix.

Huh!  Well thanks Max, that would explain it then.

Weird, random song mix is how I use all my SB players normally and it's always worked just fine.  I'll log another bug.

Bug 9330 created.

I've made it trigger a fade in when playing the fall-back sound (currently random tracks) in change 22958 (7.2).  Fade-in should now work in all situations.

Fade-in is working as of 22997.

I'm still getting a fallback (20 second pause) but it did fade in this morning.

On to bug 9330 then!