[Feature request] download location about tempo HOT 9 CLOSED

Sure :)
Update me if you need me to test it again

from tempo.

Hi, it's been a long time. These days I have added the ability to select external storage as the default storage for downloads. It's a new option within the settings, visible only if the app detects an external memory.

I was mainly slowed down by the impossibility of testing the functionality with my own physical device, so I relied on the Android Studio emulator (a love/hate relationship).

Back to functionality:
It seems to work, the download is basically handled by Media3 which uses the default app folder. Due to the increasingly stringent storage access policies adopted by Google, this allows me not to ask the user for permission to write the download.

There are three limitations:

• I can only use one storage at a time. Therefore, I cannot have files downloaded to both storages at the same time (or better, it is possible, but I can only read from one location).
• I can't move downloads from one storage to another, moving from one place to another the user must accept losing all the previously saved downloads.
• The change will take effect the first time the app is restarted, a manual operation that the user have to do.

Bottom line, would you be willing to try this new version and tell me what you think?
I'd be interested to know mainly if it works or there is strange behavior.

I am attaching to this comment a zip containing the new apk for anyone who wants to try it. Let me know!

app-tempo-debug.zip

from tempo.

Hey @CappielloAntonio 👋
Thank you for implementing this!

I just tested and works as you described!

Once I change the setting to external storage the app display this warning modal

I downloaded an album

and checked the app folder in the sdcard

After that I played the album with the device in offline mode and it worked just fine :)

I changed the download storage back to internal and all downloads were gone as you said 👍
One thing that I noticed is that the downloaded files on sdcard was still there.

Knowing that I have two suggestions:

• when the user change the storage setting you can doce close the app to make sure it was restarted
• as you will loose the reference for the files when changing storage you could delete them when changing the storage

thanks again :)

from tempo.

Hi @karlprieb, thanks a lot for the test.
To respond to your comments:

• I guess there's not much I can do to force restart the app, I could destroy and recreate the single activity, but I'm afraid it wouldn't have the desired effect for the download destination folder switch.
• That the downloads stay in the destination folder should definitely not happen, I'll do some more testing.

from tempo.

Hi @karlprieb, here we go again.

I have a few questions to ask:

• is it possible that when storage is changed and after restarting, what is left in memory are just empty folders?
• would it be possible for you to test this functionality in a clean environment, deleting all your downloads and starting from scratch?

I'm doing several tests locally (on an emulator as I don't yet have a physical device that allows me to test) and when storage is changed or storage is forced to be deleted, all the elements in the db are effectively deleted. What I do is read the db, read the downloads there, and for each download I delete the file in memory.

My doubt is that you somehow have items in memory that aren't saved in the db. This could be caused by some carelessness of mine in one of the updates or I don't know, it seems really strange to me.

from tempo.

I can test it again from a clean state, like I did on my previous test, tomorrow :)

is it possible that when storage is changed and after restarting, what is left in memory are just empty folders?

from what I remember the downloaded files were still there, but I’ll test it again to make sure.

My doubt is that you somehow have items in memory that aren't saved in the db. This could be caused by some carelessness of mine in one of the updates or I don't know, it seems really strange to me.

Maybe 🤔 maybe the download failed somehow and you didn’t inserted it in the db, but some chunks were saved in the file system. I don’t know :)
If I can reproduce it tomorrow I’ll check the code tomorrow to understand how you implemented it and maybe I can catch something.

from tempo.

Hi @karlprieb, could you use the new version of Tempo when you test it?
I released it just yesterday and while it might have some bugs due to the amount of changes made, it's a step in the right direction that the app should take.

from tempo.

Solved the problem upstream by automatically deleting the downloaded items in the db and then manually deleting any other files in the download folder if it matches the extension of the downloaded files with ".exo".

from tempo.

Sorry for not providing feedback :)
I was able to test now with the latest build and it works as expected!

from tempo.