Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Library scan: log summary and show popup #13427

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

ronso0
Copy link
Member

@ronso0 ronso0 commented Jul 1, 2024

This emphasizes the logged scan summary and allows to show a respective popup, both for automatic scan at startup and manual scan.

Fixes #10720

For me, this is a step towards being able to manually find successors for moved missing tracks, may also be helpful for the New Tracks filter/feature.

info [LibraryScanner 1] ----------------------------------------------
info [LibraryScanner 1] Library scan finished after 963 ms
info [LibraryScanner 1]  1235 unchanged directories
info [LibraryScanner 1]  197 changed/added directories
info [LibraryScanner 1]  0 tracks verified from changed/added directories
info [LibraryScanner 1]  0 new tracks
info [LibraryScanner 1]  0 moved tracks
info [LibraryScanner 1]  0 missing tracks
info [LibraryScanner 1] ----------------------------------------------

image
if nothing changed it displays only duration and ""No changes were detected."

TODO
Find an alternative for int LibraryScanner::cleanUpScan() to get the number of relocated tracks. ✔️

@ronso0 ronso0 changed the title Lib scan summary etc Library scan: log summary and show popup Jul 3, 2024
@ronso0
Copy link
Member Author

ronso0 commented Jul 3, 2024

Find an alternative for int LibraryScanner::cleanUpScan() to get the number of relocated tracks.

Simply storing that in an LibraryScanner int member seems fine to me (reset when scan is started, no need to bother scannerGlobal with this).
Wdyt?

@JoergAtGithub
Copy link
Member

show a respective popup, both for automatic scan at startup and manual scan

It's a nice addition to get a feedback, when I triggered the scan amnually. But I would no like to get this pop-up, when I start Mixxx.

@ronso0
Copy link
Member Author

ronso0 commented Jul 4, 2024

Funny thing is, I moved the connection to CoreServices so we can always get the popup.

Why do you consider the info popup disturbing / not helpful for the autorun scan during startup?

@ronso0 ronso0 marked this pull request as ready for review July 4, 2024 08:01
} // namespace
return matchLength;
}
} // namespace
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only fixing indentation, pre-commit

@ronso0
Copy link
Member Author

ronso0 commented Jul 24, 2024

friendly ping @JoergAtGithub

Why do you consider the info popup disturbing / not helpful for the autorun scan during startup?

We could make the report optional when scanning during startup, but I'd rather avoid that sort of complification / extra pref option.

@JoergAtGithub
Copy link
Member

In my opinion a dialog should only appear, if:

  • it's the response to a users action (like clicking on rescan library here)
  • an error occurs

but on startup it is always anoying to click dialogs away. Normal information should be visualize unobtrusive in the UI, in a way that does not require user action to continue.

@ronso0
Copy link
Member Author

ronso0 commented Jul 25, 2024

The last commit disables the report/summary dialog for the auto scan run during startup.

@ronso0
Copy link
Member Author

ronso0 commented Jul 25, 2024

I'm a bit puzzled why the "changed/added" directory count is not 0 repeatedly even if the dirs haven't been modified.
(no regression btw)

@ronso0
Copy link
Member Author

ronso0 commented Jul 29, 2024

I'm a bit puzzled why the "changed/added" directory count is not 0 repeatedly even if the dirs haven't been modified. (no regression btw)

Turns out it's just the confusing naming scanned vs. changed/added.
"scanned directories" are the directories where no previous hash exists (??) or prev hash != new hash (even though there was absolutely nothing even touching the dirs in between the scans 🤷 )

I adjusted the dialog and the logged lines. All good now!

@JoergAtGithub
Copy link
Member

Is it the intended behavior, that I get negative values, if I: Delete a file -> Rescan -> Restore the file -> Rescan
grafik

It would make sense to print the scan results into the log output at startup, if Mixxx is started in developer mode.

@ronso0
Copy link
Member Author

ronso0 commented Jul 29, 2024

Is it the intended behavior, that I get negative values, if I: Delete a file -> Rescan -> Restore the file -> Rescan

Thanks for your thourough testing!
This is not expected, but the numerical result of the TrackDAO/Scanner methods we had at our disposal:

  previously existing track locations
+ new tracks (= added tracks - relocated tracks)
- existing track locations

In order to reliably report rediscovered tracks I'll add a method to TrackDAO to get missing track locations.

@ronso0
Copy link
Member Author

ronso0 commented Jul 29, 2024

The report now looks like this
image

We could calculate new missing tracks but I don't think that's worth it.

@ronso0
Copy link
Member Author

ronso0 commented Jul 29, 2024

It would make sense to print the scan results into the log output at startup, if Mixxx is started in developer mode.

The report is always logged, just the dialog is now suppressed for the scan during startup.

@daschuer
Copy link
Member

I have not tested this yet and I have scanning during start up disabled so I probably not fully qualified to comment. But here some thoughts:

I think we have a scanning dialog that pops up when the scan takes longer. There is a risk that mixxx is locked when using the library during scanning. So I would argue the user is disturbed anyway by the startup scan.

On the other hand I can confirm that the scan during startup is annoying and a "useless" dialog would be more annoying.

How about showing the dialog only if new tracks are found or some are missing in the startup case?
For my use case it would be also nice to put new tracks in an "Incoming" crate.

What do you think?

@JoergAtGithub
Copy link
Member

I think the currently implemented approach with printing always to the log, but showing the dialog only when the user manually triggers the library scan is fine.

@ronso0
Copy link
Member Author

ronso0 commented Jul 30, 2024

I think we have a scanning dialog that pops up when the scan takes longer. There is a risk that mixxx is locked when using the library during scanning. So I would argue the user is disturbed anyway by the startup scan.

Exactly, the scan progress dialog pops up if the scan takes longer than 2s.
(fwiw during testing with auto-scan on startup I see the -empty- dialog artefact which never disappears, have to close it #12283)
Yes, the scan may be disturbing if one has new tracks on each start (many of them or a slow computer). And the scan during start with a fresh profile (new music dirs with lots of files) can lead to #11738 (which is why I have a delayed scan fix stashed).

@ronso0
Copy link
Member Author

ronso0 commented Jul 30, 2024

How about showing the dialog only if new tracks are found or some are missing in the startup case?

Yes, that wold make sense. new tracks, new missing tracks, track rediscovered.

@ronso0
Copy link
Member Author

ronso0 commented Jul 30, 2024

For my use case it would be also nice to put new tracks in an "Incoming" crate.

The "New tracks" feature / crate would make sense. How / when tracks are removed needs to be discussed. Automatically when a rating is set? And/or when they're sorted into playlists or crates?

I appreciate the idea, though it's unrelated to this UX fix/feature. I remember we briefly discussed this recently, is there already an Issue for tracking it?

@ronso0
Copy link
Member Author

ronso0 commented Jul 30, 2024

I think the report can be optimized. IMO this is sufficient:

Scan took 1181 ms.

1 new tracks found
0 moved tracks detected
1 tracks are missing
0 tracks have been rediscovered

16066 tracks in total

ToDo

  • count new missing tracks (change discovered during this scan)

@daschuer
Copy link
Member

The "New tracks" feature ...

My current use case would work perfectly if the tracks stick in the "Incoming" crate, just like in my email in box.

Normally I sort them from there and than weeks later I delete them they are no longer considered as "New".

@daschuer
Copy link
Member

We have this one:
#13403

I will file new one for the scanner part.

@daschuer
Copy link
Member

#13526

@ronso0
Copy link
Member Author

ronso0 commented Jul 31, 2024

The report dialog now only displays relevant information:
new / moved / new missing / rediscovered tracks only if there are any.

I'll work on a fixup to show the report dialog during startup only if changes have been detected.

@ronso0
Copy link
Member Author

ronso0 commented Aug 29, 2024

I'll work on a fixup to show the report dialog during startup only if changes have been detected.

done.

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments. Not yet tested.

while (query.next()) {
locations.insert(query.value(locationColumn).toString());
}
return locations;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you may put this lower part into a common function taking a query, and returning the QSet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, done.

numRediscoveredTracks++;
}
}
const auto missingTracks = m_trackDao.getAllMissingTrackLocations();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea how this performs and whether optimization is beneficial:
An idea for optimizion would be to move the compare loop into getAllMissingTrackLocations and get around the temporary QSet(). This will require a lot more compares though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Show summary of library rescan
3 participants