Bugzilla – Bug 13775
Improve performance of status query
Last modified: 2011-11-06 23:22:36 UTC
The status query does a ton of work and is called very frequently if the web UI is open (every 5 seconds). It's also called a lot by SP. It gets worse the more tracks you have in the playlist. Multiple database calls and other things should be looked at to see if we can reduce or eliminate these. On slow machines running with the web UI and streaming could be causing some issues, such as buffering problems some people are seeing. Another option might be to have the web UI update itself using a more lightweight query.
Its not that bad for me with a small playlist: [09-08-30 19:54:44.0325] Request 0.01935 : Slim::Control::Queries::statusQuery [09-08-30 19:55:14.0518] Request 0.01912 : Slim::Control::Queries::statusQuery [09-08-30 19:55:44.0719] Request 0.01987 : Slim::Control::Queries::statusQuery [09-08-30 19:56:14.0923] Request 0.02019 : Slim::Control::Queries::statusQuery [09-08-30 19:56:44.1128] Request 0.02027 : Slim::Control::Queries::statusQuery [09-08-30 19:56:58.7341] Request 0.01950 : Slim::Control::Queries::statusQuery [09-08-30 19:57:28.7534] Request 0.01931 : Slim::Control::Queries::statusQuery serverstatusQuery needs fixing urgently - its still making a brain dead sql query: [09-08-30 19:52:01.5356] DB Access 1.45712 : SELECT COUNT( * ) FROM (SELECT me.id FROM tracks me WHERE ( me.audio = ? ) GROUP BY me.id, me.url, me.content_type, me.title, me.titlesort, me.titlesearch, me.album, me.primary_artist, me.tracknum, me.timestamp, me.filesize, me.disc, me.remote, me.audio, me.audio_size, me.audio_offset, me.year, me.secs, me.cover, me.vbr_scale, me.bitrate, me.samplerate, me.samplesize, me.channels, me.block_alignment, me.endian, me.bpm, me.tagversion, me.drm, me.musicmagic_mixable, me.musicbrainz_id, me.lossless, me.lyrics, me.replay_gain, me.replay_peak, me.extid) count_subq: '1' [09-08-30 19:52:01.5379] Request 1.47951 : Slim::Control::Queries::serverstatusQuery
I've recently added queries about alarms in statusQuery...open to suggestions on how I could make that more efficent.
Ben - you should probably make that additional information optional by adding another query parameter (don't know whether any letter is left though :-)). The basic status query should be lean and fast.
== Auto-comment from SVN commit #28385 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=28385 == Bug: 13775 Description: this probably won't have a huge impact on the bug, but since only squeezeplay is using the alarm information in the playerstatus response, drop these calls down into the if ($menuMode) {} clause
Unassigned bugs cannot have a priority.