Bug 2813 - Rescan with playlists take long time
: Rescan with playlists take long time
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 6.5b1
: PC Linux (other)
: P2 normal with 1 vote (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-11 11:35 UTC by Erland Isaksson
Modified: 2008-09-15 14:39 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erland Isaksson 2006-01-11 11:35:40 UTC
There seems to be some sort of performance issue with rescan if you have several playlists in the playlist directory.

I have tree playlists with 200 tracks in each and totaly 2780 tracks in the database and performs a full rescan. The rescan without playlists takes less than a minute with tree playlists it takes several minutes. I also tried it with 9 playlists and then I gave up waiting after about 10 minutes of rescanning. It seems to be working because it uses about 80% CPU and if I look in the genre_track table rows are slowly added to it.

There is also a simliar problem when performing a playlist rescan with a single playlist in the playlist directory because then the full rescan works pretty fast, but when I try to perform a playlist rescan it seems to take forever.

I am using the mysql database if that matters.

Rescanning with playlists works a lot faster with 6.2.1 and 6.2.2 but in these versions entries are incorrectly removed from the genre_track table as reported in separate problem reports, which makes them unusable with several playlists.
Comment 1 Dan Sully 2006-04-10 23:05:17 UTC
Does this still happen with the latest 6.5 nightly build?
Comment 2 Dan Sully 2006-04-21 17:00:58 UTC
This should be fixed in the latest 6.5 builds. Change 6552