Bug 16096 - Alarm fadein does not work in 7.5
: Alarm fadein does not work in 7.5
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Alarm
: unspecified
: PC Windows Home Server
: P1 major with 13 votes (vote)
: 7.5.3
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-19 14:14 UTC by Kurt Poulsen
Modified: 2011-01-15 05:22 UTC (History)
7 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Poulsen 2010-04-19 14:14:34 UTC
When the alarm sounds the fade-in does not work on my Boom. It stopped working when I installed 7.5.
Comment 1 Kurt Poulsen 2010-04-21 09:01:43 UTC
And it doesn't matter what has been played before the alarm sounds.
Comment 2 Armand LECAMUS 2010-04-24 09:08:38 UTC
I confirm I got the same issue in 7.5.0 (no fade-in when the alarm sounds).
It occured that, after deletion / creation of the alarm, it worked only once and not each time.
I also tried to check/uncheck the fade-in option but it didn't work better.
A reset of the box (Boom also) didn't change anything.
Now I downgraded to 7.4.2 and it works well again
Comment 3 Mickey Gee 2010-04-26 07:49:10 UTC
*** Bug 16070 has been marked as a duplicate of this bug. ***
Comment 4 Travis Brown 2010-04-26 09:19:25 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Richard Sharpe 2010-04-26 13:59:43 UTC
This bug is categorised as a Boom issue, but is present on my SB3 (Squeezebox Server 7.5.0 running on Mac OS X), so I think this should be categorised as a Squeezebox Server issue.

I can also confirm that the issue occurs with either music library or streaming radio playlists, and (as previously reported) that both types work fine the very first time that they are configured - but not subsequently. One workaround would therefore be to creat the alarm every day... :)
Comment 6 Stefan Hansel 2010-04-26 15:45:35 UTC
could someone link bug #16054 (same annoying behaviour on the Radio) as 'see also' to this one ? If this is server related, then this bug might even be a duplicate.

Also note that issues get mixed again:

1) A lot of people are able to reproduce this with subsequent alarms (because the first alarm sets the playlist, the second one uses the same playlist) and can get rid of it, if they change the playlist between alarms to something different.

2) Then there is also the original poster who claims that for him it is playlist-unrelated (thats why he actually created this extra bug-report in addition to the others).
Comment 7 Richard Sharpe 2010-04-27 04:39:54 UTC
Bug #16054 specifically says that the issues is when playing a radio stream. My understanding from the description of this bug (although admittedly there is not a huge amount of detail here) is that it is for both library music and radio streams. I'll wait to be corrected... :)
Comment 8 Kurt Poulsen 2010-04-27 12:46:10 UTC
It doesn't matter what the source is for the alarm. I tried it from my music library and from one of my radio stream. No matter what I choose the fadein doesn't work.
Comment 9 SVN Bot 2010-04-29 12:05:29 UTC
 == Auto-comment from SVN commit #30715 to the slim repo by agrundman ==
 == http://svn.slimdevices.com/slim?view=revision&revision=30715 ==

Fixed bug 16096, alarm fade-in was broken due to fadeIn value not being passed around correctly
Comment 10 Stefan Hansel 2010-05-02 23:14:39 UTC
Andy I just tested it, and for me it still doesn't  work as expected.

I'm running: 
Server version 7.6.0 - r30722 @ Sat May 1 01:03:24 PDT 2010
and Radio Firmware: 7.5.0-r8673

(I guess your changes should have been merged automatically to 7.6.0 already?) 

I have a local alarm set on a Radio stream.
The behaviour is now the opposite to the past.

If the playlist contains a Radio stream that is also set as alarm, I get a fading in alarm.
If the playlist is paused with some other stream (Radio or Mp3) the next alarm does not fade in.

Could you please check if the bug should be opened again ?
Comment 11 Armand LECAMUS 2010-05-03 14:00:05 UTC
The bug doesn't seem to be fixed.
Tested with Version : 7.5.1 - r30709 @ Fri Apr 30 03:05:09 PDT 2010.
The existing alarm with fade-in activated and set on a radio stream has not worked.
I suppressed and recreated the alarm, still with fade-in and set on a radio stream, it worked with fade-in the first time and not after.
Comment 12 Chris Owens 2010-05-05 16:27:58 UTC
Users report this bug is not fixed.
Comment 13 UliMy 2010-05-10 08:59:45 UTC
Since the recent change my alarm on my Boom works perfectly fine again. I cannot report any bugs, but I didn't check it systematically. I work on "mysqueezebox.com".
Comment 14 Kurt Poulsen 2010-05-13 02:57:43 UTC
I have tried this on my Boom using 7.5.1 and as far as I can test this is fixed.
Comment 15 Stefan Hansel 2010-05-16 10:08:23 UTC
Kurt, this bug is not (completely) fixed, could you please reopen it.

The things I wrote in comment #10 still apply, I just tested again with the latest 7.5.1 server (7.5.1 r30756) and get the same behaviour with Radio and (!) Boom:


When the current playlist contains the same stream as the alarm, the alarm is fading in.
When the current playlist contains another stream, the alarm-stream is NOT fading in but instantly starts with the alarm volume.

Also there is a new bug-report about it (see bug #16231) which proves that other users still do have problems too.
Comment 16 Kurt Poulsen 2010-05-16 11:16:57 UTC
Stefan: You are right. It is not fixed. Sorry about this but I must have chosen a wrong stream before testing it. I have now the exact same behaviour as you on my boom.
Comment 17 Andy Grundman 2010-05-17 04:29:22 UTC
*** Bug 16231 has been marked as a duplicate of this bug. ***
Comment 18 SVN Bot 2010-05-17 07:26:08 UTC
 == Auto-comment from SVN commit #30770 to the slim repo by agrundman ==
 == http://svn.slimdevices.com/slim?view=revision&revision=30770 ==

Fixed bug 16096 again, another instance of the fadeIn param being in the wrong argument to play()
Comment 19 Michael Herger 2010-05-17 07:34:17 UTC
*** Bug 16070 has been marked as a duplicate of this bug. ***
Comment 20 Michael 2010-05-17 13:32:04 UTC
It seems to work for my Radio running SBS 7.60. Thanks Andy!

However, when connected to Mysqueezebox.com, it still doesn't fade. No matter if you continue a playlist or not.

Michael
Comment 21 Kurt Poulsen 2010-05-19 11:50:49 UTC
It works for me too now. Thanks Andy.
Comment 22 Michael 2010-05-27 00:37:37 UTC
After some testing, the fade is still broken.

Whenever your alarm continues a playlist (either local or as a stream), the following happens:

Music starts on a very low volume for about 10 seconds, and then jumps to the defined maximum alarm volume. I'm currently using firmware 7.51 Build 8805 on the Radio and SBS 7.60 30824 but this also happend with the former firmware and former SBS versions.

Still very annoying. Can anyone confirm this? As long as you choose a different stream other the one that was played last, the fade works.

Michael
Comment 23 Wilco 2010-05-28 23:40:44 UTC
Same problem here. I'll hope it will be fixed in next firmware.
Comment 24 Michael 2010-05-31 00:35:33 UTC
(In reply to comment #23)
> Same problem here. I'll hope it will be fixed in next firmware.

It's supposed to be a problem on the server side, not the firmware.

At the moment, the behaviour is quite random. Yesterday it managed to fade in smoothly, the next day  it was on low volume for 10 seconds, then jumped to max volume again. 

Andy, it would be nice if you could take a look into the code again.
Comment 25 Michael 2010-06-08 22:25:32 UTC
Just happened again and made me jump out of my bed ...

Alarm was set to a playlist with about 200 songs to be played in random order.

The sound started with minimum volume, playing about 10 seconds at this level, then all the sudden jumps to the maximum set volume.

Radio firmware 7.51 Build 8837 / SBS 7.60 Build 30847

I really hope it's possible to fix this darn fade-in problem once and for all.
Comment 26 Kurt Poulsen 2010-06-09 12:43:57 UTC
It sounds like this bug is not fixed yet.
Comment 27 Michael 2010-06-09 14:43:27 UTC
No, by all means it's not fixed yet.

This morning I did some testing. I set up about 8 alarms, and I *never* got radio to fade in correctly.
Comment 28 Chris Owens 2010-06-10 09:06:35 UTC
There are definitely fixes for some of these issues in 7.5.1 but it sounds like some people are still seeing issues.  We'll continue to look into the remaining issues.
Comment 29 Michael 2010-06-10 15:51:17 UTC
I'm using the latest 7.60 - I assume the fixes for 7.50 made it into 7.60 aswell ?
Comment 30 Chris Owens 2010-06-10 16:17:36 UTC
This isn't easily reproducible for me, but I'll keep at it.  Maybe Michael's idea of 8 alarms will work for me.
Comment 31 Michael 2010-06-11 04:23:40 UTC
Chris,

would it help to provide a server-log and the log from the SB Radio at the moment the alarm fires ?
Comment 32 Alan Young 2010-07-16 01:57:18 UTC
*** Bug 16054 has been marked as a duplicate of this bug. ***
Comment 33 Alan Young 2011-01-14 01:01:16 UTC
Fade-in is certainly working for me with 7.5.3 (and was with 7.5.2)
Comment 34 Kurt Poulsen 2011-01-14 15:56:15 UTC
In my opinion it has been fixed for a long time!
Comment 35 Andy Grundman 2011-01-15 05:22:10 UTC
Yeah this is fixed.