10-03-2020, 05:18 AM
Deleting thousands of songs at once can take awhile, but it depends on a variety of factors, including:
1) Are you using local storage or a removable SD card? Local storage is usually much faster on most devices. If you use the default application storage location on a removable SD card, then it should still be pretty fast. If you use a custom storage location, due to Google's "Storage Access Framework", each file deletion is going to be horribly slow. So if you are encountering issues with the application not responding, this could be part of it. That's still a bad sign though, as it means I'm not deleting everything in a background thread, so I'll have to update the code to properly handle that.
2) The amount of information being deleted from the database. I use a single transaction per deleted song, but this is also bad, as it means changes will be committed to the database after each song deletion, which is going to be slow for thousands of songs. I will need to update the code to use a single transaction. This could speed things up dramatically.
So I'll go through an update the code to help make this a lot faster. As far as the ordering of deletions with files, with solid state memory, this really doesn't have a significant impact, and if you use the default settings, MobileSheetsPro uses a different folder per song, so there really shouldn't be file shuffling. I also don't sort things based on file paths, so the order would be difficult to determine anyways.
As for the library matching, I don't support matching on multiple fields beyond the primary selected field and file name if there happens to be multiple matches. If necessary, I can try to update the logic to look through additional fields in the case that there is an exact match for both the primary field as well as file path. I would probably compare collections first, then custom group, then the other fields.
Mike
1) Are you using local storage or a removable SD card? Local storage is usually much faster on most devices. If you use the default application storage location on a removable SD card, then it should still be pretty fast. If you use a custom storage location, due to Google's "Storage Access Framework", each file deletion is going to be horribly slow. So if you are encountering issues with the application not responding, this could be part of it. That's still a bad sign though, as it means I'm not deleting everything in a background thread, so I'll have to update the code to properly handle that.
2) The amount of information being deleted from the database. I use a single transaction per deleted song, but this is also bad, as it means changes will be committed to the database after each song deletion, which is going to be slow for thousands of songs. I will need to update the code to use a single transaction. This could speed things up dramatically.
So I'll go through an update the code to help make this a lot faster. As far as the ordering of deletions with files, with solid state memory, this really doesn't have a significant impact, and if you use the default settings, MobileSheetsPro uses a different folder per song, so there really shouldn't be file shuffling. I also don't sort things based on file paths, so the order would be difficult to determine anyways.
As for the library matching, I don't support matching on multiple fields beyond the primary selected field and file name if there happens to be multiple matches. If necessary, I can try to update the logic to look through additional fields in the case that there is an exact match for both the primary field as well as file path. I would probably compare collections first, then custom group, then the other fields.
Mike