Review Request: Preview of live scanning feature

Bart Cerneels bart.cerneels at kde.org
Mon Feb 27 09:53:20 UTC 2012


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104049/#review10944
-----------------------------------------------------------


Please use the reviewboard when responding to reviews. It's impossible to keep track when switching between this and the mailing list.

> As i mentioned, this is just a preview so i am not interested in code
> style issues at this point. 

The point of a coding style is having consistent readable code. As I mentioned this code is to complex to also have to parse a different coding style as well.

> Are the actual changes to scanner logic
> good and should i continue the work? If yes, next steps would be
> implementing partial scan and deleting missing files from database.
>
> Any ideas how to implement deletion are welcome. I'm not sure if it
> should be done in amarok or scanner process.

I think it's a good idea to have the scanner process only list the current contents of the folder. When updating a collection, after the scanner is done, you could go over the list of tracks and find what was not reported. Then you should remove those tracks.

Thinking of an efficient technical step-by-step:
1) Mark all tracks as removed (in memory, using hash on database uniqueurl for instance).
2) Run scanner process, update QHash (clear bit "removed") for each reported track.
3) After scanner is done apply the removed bits to the database, but don't actually delete the tracks that were not found during the update.
4) Either after every update scan (those can run automatically) or manually from the menu > tools; offer a removed tracks review-and-confirm dialog. This will truly remove rows from the database.

This would get around the possibility of removing all tracks by accident because of bad configuration or missing mounted filesystem, yet dramatically improving performance because of live scanning and shorter code path in parsing scanner output.
I think those steps make it easier to reuse collectionscanner in more Collection plugins (like USB Mass Storage) as well.

- Bart Cerneels


On Feb. 23, 2012, 2:25 p.m., Ville Ranki wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104049/
> -----------------------------------------------------------
> 
> (Updated Feb. 23, 2012, 2:25 p.m.)
> 
> 
> Review request for Amarok.
> 
> 
> Description
> -------
> 
> This is a preview of work i've been doing to implement live scanning. Currently it can do full scan 
> and add found tracks to database during the scan. Removing missing files is not yet implemented. Also partial 
> scan may not work as expected.
> 
> 
> Diffs
> -----
> 
>   src/core-impl/collections/db/ScanManager.h 5f0d153 
>   src/core-impl/collections/db/ScanManager.cpp 97d0b1c 
>   src/core-impl/collections/db/ScanResultProcessor.cpp 4f02a16 
>   src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp 6699b98 
>   src/scanner/GenericScanManager.cpp 215f78b 
>   utilities/collectionscanner/CollectionScanner.h 6bbc757 
>   utilities/collectionscanner/CollectionScanner.cpp 74b57a6 
>   utilities/collectionscanner/Directory.cpp 66b3a9b 
> 
> Diff: http://git.reviewboard.kde.org/r/104049/diff/
> 
> 
> Testing
> -------
> 
> "Works on my pc" on a small test collection.
> 
> 
> Thanks,
> 
> Ville Ranki
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20120227/21e84b73/attachment.html>


More information about the Amarok-devel mailing list