Users are not going to many of see the improvements to the music library when they upgrade to V17 from earlier versions unless they rescan the additional tags that v17 processes from their music files. However there is no easy way for users to initiate a rescan of exsisting files without either a) dropping that source and losing their playcount data etc or b) "touching" the music files so that Kodi thinks they have changed. A library update started by the user will only check the hash table, it then only scans the tags of those that have a different name or timestamp.
On the otherhand a rescan on migration can be forced, but for those users that don't have those tags in their music files such as scan would be a waste of time. And even for those that want it, the timing of the rescan on the first run of Kodi may be inconvenient.
So the question: do we force a rescan when upgrading to v17 or not?
It is something that a user can cancel, but unfortunately they can not restart it at a later date.
Persoanlly I would like the 3rd option - give users the ability to force their own rescan of tags from every file regardless of lack of hash table differences - but I'm not sure that can be provided in time for release.
How about adding a new "Full Library Scan" option in Kodi's the Music Expert menu (with a warning that it will take a while).
Is it possible to schedule this rescan to an idle time? Like give three options: 1) No rescan 2) Rescan now 3) Rescan later
It would then need some trigger to initiate the rescan when option 3 was chosen.
Edit because reading helps:
(2016-10-19, 19:57)DaveBlake Wrote: [ -> ]It is something that a user can cancel, but unfortunately they can not restart it at a later date.
Persoanlly I would like the 3rd option - give users the ability to force their own rescan of tags from every file regardless of lack of hash table differences - but I'm not sure that can be provided in time for release.
Hmmm, tough choice in this case. With large music database rescanning will take quite long, meaning after the update kodi will be hardly usable during the rescan process. I still vote for the rescan. Progress comes with some pain sometimes.
(2016-10-22, 11:02)DarkHelmet Wrote: [ -> ]Is it possible to schedule this rescan to an idle time? Like give three options: 1) No rescan 2) Rescan now 3) Rescan later
It would then need some trigger to initiate the rescan when option 3 was chosen.
Edit because reading helps:
(2016-10-19, 19:57)DaveBlake Wrote: [ -> ]It is something that a user can cancel, but unfortunately they can not restart it at a later date.
Persoanlly I would like the 3rd option - give users the ability to force their own rescan of tags from every file regardless of lack of hash table differences - but I'm not sure that can be provided in time for release.
Hmmm, tough choice in this case. With large music database rescanning will take quite long, meaning after the update kodi will be hardly usable during the rescan process. I still vote for the rescan. Progress comes with some pain sometimes.
In this case i certainly share your opinion. Rescanning can be a bitch but unless it's kinda forced upon users it won't really happen. Hidding the "force rescan" will unlikely be found really fast by average users.
Of course after Kodi update your installation shouldn't be unusable for hours or days.
In the past we did something similar where we threw a yes/no dialog asking the user to rescan their library. So this could be done again
Quote:We would like to trigger a rescan of your library. This could take some time depending on the size. Would you like to start?" -> "YES / NOT NOW"
Martijn, I believe "not now" is not really possible. After an update to Krypton a new music database version is created. Coming from Jarvis with a db version 56 the Krypton version 60 is created regardless if you rescan or not. Only with a rescan the new tags will be used for the version 60 though. Saying "Not now" basically means "Never", since only advanced users will know what to do to update the then existing version 60 with new tags (delete source, then readd or "change" anything in ALL files so kodi thinks they're new files). Choosing "not now" would result in a database 60 without any new stuff, basically a version 56 that is called 60 from now on if I understand Dave correctly.
Instead of a dialogue if the decision is made to force a rescan it should rather be a warning "Your music database will be rescanned now, this will take a while depending on the size of your database" and you can only click "okay" to acknowledge that. The way i see it any other option would basically mean "Never".
No this case is different. For the scan we just need to ignore the current file hashes one time and it will rescan all files but keep all play counts and so on. The "not now" will simply defer it x days or whatever and it would ask again.
Martijn, that would be the best solution. From Dave's initial post I had my doubts this is possible though.
All is possible. It just depends whats the best method and how much changes it would need to do it.
Currently the question is what should we ask and do it in the best possible and common user friendly way. Then look at technical needs to get that done.
My vote is for rescan at a time chosen by the user like you proposed. Opting out completely should not be an option but the time of the rescan should be optional.
It seems I may have the ability to offer more than just the force scan or don't options I initially thought. I still find it so hard to judge what the team is happy about fitting in before relealse and what they aren't. But still good to know how people feel about forced rescanning (for their own good), so still vote in the poll.
So other options:
a) a simple full tag rescan (regardless of timestamps) facility.
b) A prompt that comes up when you first enter the music library after migration from an earlier version of Kodi that offers to "rescan now?" yes or no.
If you say yes then it does it, but if scanning is interrupted it will not know to offer this again. If you say no then it will work with the library as it is it, but next time you enetre the music libaray it will ask you again.
c) A prompt that comes up when you first enter the music library after migration from an earlier version of Kodi that offers to "rescan now", "rescan later" and "never rescan". First two replies are same as yes and no above, but have the 3rd option to stop pestering you. With that you will not be asked again.
I see b) and c) as alternatives we only need one of them, but persoanlly I would also have a). I see a) as useful if users either interrupt scanning, or choose "never" and then later change their minds. Much like library clean, if is not something you need to use often, but it is always useful to cover all eventualities and make it possible to manually initiate functions that are normally automatic. I know that others see a) as unfriendly and unnecessary clutter of the UI.
Edit: and having found that b) or c) we can always edit guisettings.xml to make it as if we had not been through the process, I can see there is a way around not having a) should a user cock up.
With b) or c) a more complicated variant would be have a variable pester frequency - delay x days before asking again. But to be honest either you are going to rescan soon and just delaying because right now is not the best moment, or the whole thing becomes irrelevent.
So do we need c) and the ability to say never, or is stopping scanning on b) enough for those that want the pestering to stop and really don't want to rescan ever?
Also need to try to stop the rescanning of tags from music files also rescraping online metadata, which can take considerably longer.
(2016-10-22, 14:12)DarkHelmet Wrote: [ -> ]My vote is for rescan at a time chosen by the user like you proposed. Opting out completely should not be an option but the time of the rescan should be optional.
Sounds like you would like to shedule the rescan? I can see why that could be attractive, but not sure I want to get into sheduling for what is generally a do once an forget activity. Would being invited to rescan everytime you entered the music libaray be enough?
Scheduling just in the sense of when I enter the music library after before having said "Rescan later" I get asked again if I want to rescan now. If possible I think that's a good way to go with this.
You brought up the case where a rescan is interrupted (loss of internet connection for example). What actually happens then? Can Kodi detect that (% of music files scanned?), fall back to db 56 from Jarvis and try again? The advanced user can of course manually delete the db version 60 but not everybody might have that knowledge.
(2016-10-22, 20:13)DarkHelmet Wrote: [ -> ]Scheduling just in the sense of when I enter the music library after before having said "Rescan later" I get asked again if I want to rescan now. If possible I think that's a good way to go with this.
You brought up the case where a rescan is interrupted (loss of internet connection for example). What actually happens then? Can Kodi detect that (% of music files scanned?), fall back to db 56 from Jarvis and try again? The advanced user can of course manually delete the db version 60 but not everybody might have that knowledge.
Basic file scan doesn't need internet at all. Only if you have "look up additional information" enabled which is by default off. If you have and internet dies Kodi will start nagging you it can't go further. So in that case we'd need to not flag scan as complete and try again next time.
That's a question I had. Is it possible to do a "rescan" that just does tags and doesn't run artist/album scrapers (at least if lastScraped is not null)? AFAICT, I don't see any reason to run the scrapers due to updating to v17, though in some cases if user changed MBIDs it might make a difference (mainly to artists, not so much albums). But these I think could be handled individually, not in a programmed re-scan.
I like the option c of now/later/never.
Does a rescan keep the date added sequence?
scott s.
.
(2016-10-22, 22:36)scott967 Wrote: [ -> ]That's a question I had. Is it possible to do a "rescan" that just does tags and doesn't run artist/album scrapers (at least if lastScraped is not null)? AFAICT, I don't see any reason to run the scrapers due to updating to v17, though in some cases if user changed MBIDs it might make a difference (mainly to artists, not so much albums). But these I think could be handled individually, not in a programmed re-scan.
It is possible, and as you point out there is not reason for force a rescrape (in fact good reason not to), but this has to be designed in. The last time we did a forced rescan this was not considered and it also did an unnecessary rescrape. Anything I produce will consider this.
Quote:Does a rescan keep the date added sequence?
The delete/insert approach to updates means no, I don't think so. But I would need to test.
The "date added" field is usually filled with the file timestamp hence that will remain the same. But the delete/insert approach to updates means that the id order will most likely change - it will become the scanning sequence (digging into folders alphabetically). We use id order for the recently added node (not date added because it isn't the date added), so post rescan your recently added node results will look different.