Bugzilla – Bug 16922
AudioScrobbler plugin repeatedly writes to prefs/plugin/audioscrobbler.prefs preventing disk spindown
Last modified: 2011-05-13 09:32:04 UTC
It seems to be that, if there is something in the queue (e.g. because the track is paused and the Player is currently turned off, so the queue never updates or empties), the audioscrobbler.prefs file gets touched repeatedly - possibly because sub submitScrobble in AudioScrobbler/Plugin.pm always does a setQueue even if queue hasn't changed. This has the effect of updating the _ts_queue entry in the prefs file but nothing else. On a system with a disk spindown capability, this seems to prevent the disk from ever spinning down. a non-scientific fix might just compare $queue at the point prior to setQueue, with the $queue originally obtained at the top of sub submitScrobble - if unchanged, don't setQueue at all. This might then have the effect of allowing the disk to spindown if no queue changes take place.
In addition, if debug logging is enabled for plugin.audioscrobbler, the following message appears in logfile repeatedly (every minute), which is consistent with the frequency of _ts_queue timestamp updating in the prefs/audioscrobbler.prefs file: [11-02-09 23:24:30.0027] Slim::Plugin::AudioScrobbler::Plugin::submitScrobble (841) Scrobbling 1 queued item(s) [11-02-09 23:24:30.0112] Slim::Plugin::AudioScrobbler::Plugin::submitScrobble (862) Track Your%20Track%20Name%20Here is still playing, not submitting [11-02-09 23:25:30.0026] Slim::Plugin::AudioScrobbler::Plugin::submitScrobble (841) Scrobbling 1 queued item(s) [11-02-09 23:25:30.0109] Slim::Plugin::AudioScrobbler::Plugin::submitScrobble (862) Track Your%20Track%20Name%20Here is still playing, not submitting I think the following small change would actually resolve the repeated updates to prefs/audioscrobbler.prefs : move the setQueue( $client, $queue ) from line 888 of Slim/Plugin/AudioScrobbler/Plugin.pm , to inside the following if ( @tmpqueue ) block. My reasoning is this: tmpqueue is non-empty if and only if the queue contains any items beyond a single currently-playing track. if the queue contains only a single currently-playing track, then that queue item gets shifted out of the queue (in the block building tmpqueue) and then shifted back into the queue (immediately afterwards). Everything else in the queue ends up in tmpqueue. So if tmpqueue is empty, then queue must either have originally been empty or containing just a single currently-playing track. And queue will therefore still either be empty or contain just that one track. In that case, just don't setQueue, since it's the same before as it is after.
Created attachment 7145 [details] patch on top of 7.6 trunk server
At least one user forum thread discusses this exact problem although not enough information to confirm users have same root cause as mine. http://forums.slimdevices.com/showthread.php?p=610469#post610469
== Auto-comment from SVN commit #32241 to the slim repo by agrundman == == http://svn.slimdevices.com/slim?view=revision&revision=32241 == Fixed bug 16922, patch from Dave Hooper to fix unnecessary writes of AudioScrobbler prefs file
I'm happy to see this included in 7.6. The fix still works like a charm. Would it be possible to include it in the current 7.5 version?
closing per comments