GNOME Bugzilla – Bug 610800
At startup, Banshee should check for changes in the folder watched, when LibraryWatcher is turned on
Last modified: 2020-03-17 08:52:13 UTC
many times i start banshe and folder watcher does nothing. it should do a checkup once whne banshee starts.
I'm experiencing the same problem (behavior). Since folder watch extension will only be effective while Banshee is running, any change made to the library while Banshee is off will be missed. To correct this, an automatic library update performed at Banshee launched should be implemented (maybe as an option, for those who don't want to have a startup time penalty). Thanks.
Confirming. What I think we need for this bug is: 1) Get the patch of bug 638889 committed. 2) Taking advantage of the functionality implemented in bug 638889, create a patch here to do an automatic Import operation at startup if LibraryWatcher is on. 3) Create another patch to not only auto-import, but also auto-remove non-existant elements at startup. This patch should be done very carefully because there may be people that have music imported from external hard disks, and in case the hard disk is not mounted, the tracks shouldn't be removed. I'm also removing the dependency to bug 610800 because this is not a bug in the LibraryWatcher, but an enhancement request.
I would love to see this as well. It is quite confusing to have the library watcher enabled but nothing happening unless you make changed while Banshee is running. It is not the behaviour you would expect. Fixing this issue would reduce the amount of issue reports. I've seen a few issues which are basically redundant after this is fixed.
I forgot to mention that the issue got more severe with the close/quit changes in Banshee 2.0. Banshee will now quit more often instead of closing, thus not tracking library changes.
(In reply to comment #2) > I'm also removing the dependency to bug 610800 because this is not a bug in the > LibraryWatcher, but an enhancement request. For the record, in this comment, I meant bug 638939, not bug 610800 (which is this bug itself).
BTW, I've marked bug 577225 as a dependency because if we implement this without that bug being fixed, we could make the user loose data.
Created attachment 233385 [details] [review] Proposed patch
Created attachment 233634 [details] CPU spike With a library of 4,000 songs, a rescan takes about only 6 seconds in my laptop and this is the CPU spike experienced. For the test, previous to the rescan operation and while Banshee was off, I removed an album, added a new one, and moved one to a different place. IMHO despite the CPU spike, rescan is very fast and should be considered part of LibraryWatcher, since it's still opt-in. Maybe before turning LibraryWatcher ON by default, what we have to consider is getting this fixed https://bugzilla.novell.com/show_bug.cgi?id=540524. I, for one, will try to find time to get the BNC ticket above fixed.
(In reply to comment #8) > getting this fixed https://bugzilla.novell.com/show_bug.cgi?id=540524. > > I, for one, will try to find time to get the BNC ticket above fixed. Oops, sadly that would require root privileges to work. :-m
(In reply to comment #9) > (In reply to comment #8) > > getting this fixed https://bugzilla.novell.com/show_bug.cgi?id=540524. > > > > I, for one, will try to find time to get the BNC ticket above fixed. > > Oops, sadly that would require root privileges to work. > > :-m Yay, I also found this: http://stackoverflow.com/questions/14370050/nice-scheduling-priority-for-threads-within-a-process-instead-of-just-for-a-si
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.