Bug 9189 - _addJiveSong causes slow statusQuery responses, especially without cover-art
: _addJiveSong causes slow statusQuery responses, especially without cover-art
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Controller
: 7.1
: PC Fedora
: -- normal (vote)
: Future
Assigned To: Ben Klaas
:
Depends on: 9194 9400
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-17 04:01 UTC by Alan Young
Modified: 2010-08-24 04:16 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Young 2008-08-17 04:01:31 UTC
statusQuery -> _addJiveSong takes c. 1s per track on my 1GHz, slow-disk system. With a playlist of 15 or more songs this pretty-much consumes all the server resources.

More details. The worst offender is the call to '$track->coverArtExists() ', which takes c. 84ms but only when the track does not have cover-art. If it has cover-art then there is no problem. The second expensive call is '$artistObj = $track->artist() ' which costs 11ms.

On my 2.5GHz (Athlon 4800+ 64-bit dual-core) system with fast disks, these numbers are 10ms and 4ms respectively. 

Overall,  _addJiveSong seems to be very expensive, especially given that it is called every 30s from every connected SBC. The status query is taking 110ms for a 15-track playlist with cover art on my fast system.
Comment 1 Andy Grundman 2008-08-17 04:37:15 UTC
Yeah lots of room for improvement in the artwork code.
Comment 2 Blackketter Dean 2008-08-17 09:50:14 UTC
Alan: Is your recent patch to address this?  Is this a 7.2 fix?
Comment 3 Alan Young 2008-08-17 10:17:14 UTC
Yes, it does address that, but It feels rather risky to me to include in 7.2. I have only done minimal testing.
Comment 4 Alan Young 2008-09-05 01:09:38 UTC
The artwork non-caching issue had been moved to bug 9400. The fact that Track::artist() is also expensive and relevant now covered in bug 9194. Unassigning and untargeting for reconsideration with respect to further issues