Bug 2289 - Replaygain volume adjustment fails during ffwd/rew
: Replaygain volume adjustment fails during ffwd/rew
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: unspecified
: PC Windows XP
: P2 normal with 5 votes (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-13 22:54 UTC by yann oehl
Modified: 2008-09-15 14:39 UTC (History)
5 users (show)

See Also:
Category: ---


Attachments
convert.conf (5.32 KB, application/octet-stream)
2005-10-14 19:16 UTC, yann oehl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yann oehl 2005-10-13 22:54:57 UTC
Replaygain volume adjustmet fails during ffwd/rew.
Playing FLAC files, replaygained with foobar2000 software.
Using Smart gain. In shuffle by song mode.

See thread:
http://forums.slimdevices.com/newreply.php?do=newreply&noquote=1&p=53053
Comment 1 Dan Sully 2005-10-14 10:44:34 UTC
Yann - did you change your convert.conf to include replaygain parameters on the flac command line?
Comment 2 yann oehl 2005-10-14 11:19:11 UTC
Dan, I'll check out my convert.conf this eve. I don't remember changing anything
manually. BTW: Flac = <built-in>
  
Comment 3 KDF 2005-10-14 11:37:56 UTC
does the replaygain return when you go back into normal playback mode? 

Comment 4 yann oehl 2005-10-14 11:53:26 UTC
For me, it returns to normal on playback. But for others it doesn't (see thread)
Comment 5 yann oehl 2005-10-14 19:16:08 UTC
Created attachment 905 [details]
convert.conf
Comment 6 yann oehl 2005-10-14 20:11:23 UTC
I take it back. On further investigation, the gain does =not= return to normal
after scanning has stopped. Stopping or pausing has no effect, the track must be
restarted by pressing rew and re-queuing the track. 
Comment 7 Blackketter Dean 2005-10-17 16:24:48 UTC
We're not going to get to this for 6.2.  
Comment 8 Mark Lanctot 2006-01-15 08:53:12 UTC
This behavior is also present with MP3 playback.
Comment 9 yann oehl 2006-06-13 09:06:59 UTC
No one else seems to care for this request... and I've found alternative ways of doing this using Moose. No need to clutter up the request queue. 
Comment 10 yann oehl 2006-06-13 09:10:08 UTC
(In reply to comment #9)
> No one else seems to care for this request... and I've found alternative ways
> of doing this using Moose. No need to clutter up the request queue. 
> 

Whoops... sorry about that. Please ignore the above. I posted on the wrong bug. BTW: Is it possible to delete/edit bug comments?
Comment 11 Chris Owens 2006-08-16 14:31:20 UTC
Dean asserts we should fix this for 6.5.  He thinks we are just not setting the replay gain when we ffwd, and only needs to happen on server side.
Comment 12 Blackketter Dean 2006-08-22 11:51:44 UTC
I believe that we're just not setting the replaygain value in the play slimproto command when in trick mode.
Comment 13 Dan Sully 2006-08-22 15:24:31 UTC
This should fix it:

=== Slim/Player/Source.pm
==================================================================
--- Slim/Player/Source.pm       (revision 15591)
+++ Slim/Player/Source.pm       (local)
@@ -793,8 +793,14 @@
 
                my $paused = ( Slim::Player::Sync::isSynced($client) ) ? 1 : 0;
 
-               $everybuddy->play($paused, $client->streamformat(),
-                               Slim::Player::Playlist::song($client));
+               $everybuddy->play(
+                       $paused,
+                       $client->streamformat(),
+                       Slim::Player::Playlist::song($client),
+                       0,
+                       $client->shouldLoop,
+                       Slim::Player::ReplayGain->fetchGainMode($client),
+               );
 
                $everybuddy->playmode("play");
        }
Comment 14 KDF 2006-08-22 20:42:07 UTC
I forced a FLAC file to -20db replaygain to test this.  At scanning, it was still a the replaygained volume.
I tested with MP3 as well altering a file of -9 to -30 to prove it works.

it took a bit of shuffling, it seems that altering replaygain value isn't enough to change the timestamp and trigger a rescan of the file.  I had to move them to new locations.
Comment 15 Dan Sully 2006-08-22 20:58:16 UTC
Fixed in change 9117