[!NOTE]
This is for documentation purposes for fixing in the future.
Summary
When testing out the enforcement of only saving audio files in the Music directory, I encountered an issue with the app detecting the file in its original location in addition to it being in its new location.
This is a pretty big problem and can cause a bunch of issues — one is noted in 2e4242d, where I fixed the issue for if we moved an individual file.
Another issue I saw is that the id of the moved files sometimes changed, so logic to compare if a track of a given id has different uris doesn't work in this case. This means when reading the media file on the device, we get the old cached location of the file with its original id and the new location with a different id.
Work Around
This happened when I move the file around (via plugging in the device to a PC and using USB File Transfer preference). A way to avoid this caching behavior is to copy & paste the contents in the new directory and delete the original reference.
Summary
When testing out the enforcement of only saving audio files in the
Musicdirectory, I encountered an issue with the app detecting the file in its original location in addition to it being in its new location.This is a pretty big problem and can cause a bunch of issues — one is noted in 2e4242d, where I fixed the issue for if we moved an individual file.
Another issue I saw is that the id of the moved files sometimes changed, so logic to compare if a track of a given id has different uris doesn't work in this case. This means when reading the media file on the device, we get the old cached location of the file with its original id and the new location with a different id.
Work Around
This happened when I move the file around (via plugging in the device to a PC and using USB File Transfer preference). A way to avoid this caching behavior is to copy & paste the contents in the new directory and delete the original reference.