Scanning report goes over 100%

Bug #267240 reported by zp
20
Affects Status Importance Assigned to Milestone
Moovida
Fix Released
Critical
Olivier Tilloy

Bug Description

I open Elisa and entered the Music section. The Scanning widget reported that it was scanning 20000+% of my music

Olivier Tilloy (osomon)
Changed in elisa:
milestone: none → 0.5.x
Revision history for this message
zp (zekopeko-deactivatedaccount) wrote : Re: Scanning report goes over 100% in 0.5.9
Revision history for this message
Guillaume Emont (guijemont) wrote :

I've experienced this under linux, with a music directory containing mostly symlinks to places where the music actually is.

Changed in elisa:
status: New → Confirmed
yyoyo (lionel.martin)
Changed in elisa:
importance: Undecided → High
yyoyo (lionel.martin)
Changed in elisa:
assignee: nobody → lightyear
Revision history for this message
Benjamin Kampmann (lightyear) wrote :

I explained this issue would happen at the time I was told to implement this feature. There is even a FIXME around it. To explain again why this happens:

To calculate the amount of files we are scanning we use a very simple os.walk. This os.walk is the fastest way to find all the files but it has two major problems: it is *not* following any symlinks (I am not sure for hardlinks) on linux and no .LNK-Files on Windows (which is the system for file system linking there). So files inside these directories are not counted. But atm the media scanner is using LocalResource and LocalResource is a bit more intelligent than os.walk. It figures out if something is a link (sym- or hardlinks on Linux and .LNK-Files on Windows) and acts accordingly. That means that the media scanner is entering such links if they are directories.

Because of that the media scanner estimation is likely to be wrong if there are any kind of links inside the media directories. There are three ways to fix this:
 - deactivate the link following during scan (not wanted)
 - follow links in counting (would slow down the estimating)
 - rewrite the whole part to use in any case the same system for estimating AND scanning (so that there would always be a consistency of the way the file system is build into a tree)

The last one is the only proper fix to this issue but I am not sure about how much time that would take.

Olivier Tilloy (osomon)
Changed in elisa:
assignee: lightyear → nobody
Revision history for this message
O2 (m-ottosson) wrote :

I am using version 0.5.23 and is having the same same problem with scanning over 100%. After reading the posting from Benjamin above I checked if I have any links. The result is that I have no links at all in my music folders still it is scanning over 100%. Please see attcahed screenshot

Revision history for this message
Olivier Tilloy (osomon) wrote :

Are you sure you don't have any links? On windows by default the music library includes the "My Music" folder which, if I'm not wrong, contains a shortcut to "Shared Music" or something of that kind. That would explain the scanning going over 100%. You can remove the default music folder from your library by going to Music/Music Library/Folders/Add folders.

Olivier Tilloy (osomon)
Changed in elisa:
assignee: nobody → osomon
importance: High → Critical
milestone: 0.5.x → 0.5.27
Revision history for this message
Olivier Tilloy (osomon) wrote :

Note: python 2.6 added the followlinks parameter to the os.walk function (http://www.python.org/doc/2.6/library/os.html#os.walk). I reckon it would be pretty easy to copy its implementation.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Of the possible solutions listed by Benjamin at comment #3, the first one is not acceptable, nor is the third one for performance reasons. I therefore went for implementing a custom walk that follows symlinks (as done in python 2.6) and resolves windows shortcuts. See attached branch.
A merge request is pending.

Changed in elisa:
status: Confirmed → In Progress
Changed in elisa:
milestone: 0.5.27 → 0.5.28
yyoyo (lionel.martin)
Changed in elisa:
milestone: 0.5.28 → 0.5.29
Changed in elisa:
milestone: 0.5.29 → 0.5.30
Olivier Tilloy (osomon)
Changed in elisa:
milestone: 0.5.30 → 0.5.31
Olivier Tilloy (osomon)
Changed in elisa:
status: In Progress → Fix Committed
Olivier Tilloy (osomon)
Changed in elisa:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.