-
Notifications
You must be signed in to change notification settings - Fork 5
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
[Bug]: Data folder resets itself regularly #390
Comments
Is this a consistent issue or is it sporadic? |
It is consistent. Whenever I close the application, it will be reset upon restart. If I just switch applications after having changed the data directory again, then it persists for some time (I guess until Android closes it to free up memory?) |
Could it be a permissions issue? Every time I reset the directory, I need to grant permission again. But Freetube does not show up as having asked for any permissions at all, even just after I've reset the folder and granted permission. |
I'm unsure if it is a permissions issue. It might be easier to know by checking the console log on the nightly version. Does it manage to write the file |
Yes, it has no issues with that. When it resets, this file also remains intact with no changes. The contents of the file is pasted below (I have the data set up in {
"directory":"content://com.android.externalstorage.documents/tree/primary%3AFreeTube",
"files":[
{
"uri":"content://com.android.externalstorage.documents/tree/primary%3AFreeTube/document/primary%3AFreeTube%2Fsettings.db",
"fileName":"settings.db",
"isFile":true,
"isDirectory":false},
{
"uri":"content://com.android.externalstorage.documents/tree/primary%3AFreeTube/document/primary%3AFreeTube%2Fhistory.db",
"fileName":"history.db",
"isFile":true,
"isDirectory":false},
{
"uri":"content://com.android.externalstorage.documents/tree/primary%3AFreeTube/document/primary%3AFreeTube%2Fplaylists.db",
"fileName":"playlists.db",
"isFile":true,
"isDirectory":false},
{
"uri":"content://com.android.externalstorage.documents/tree/primary%3AFreeTube/document/primary%3AFreeTube%2Fprofiles.db",
"fileName":"profiles.db",
"isFile":true,
"isDirectory":false}
]
} How I think it should look: {
"directory":"content://com.android.externalstorage.documents/tree/primary/FreeTube",
"files":[
{
"uri":"content://com.android.externalstorage.documents/tree/primary/FreeTube/settings.db",
"fileName":"settings.db",
"isFile":true,
"isDirectory":false},
{
"uri":"content://com.android.externalstorage.documents/tree/primary/FreeTube/history.db",
"fileName":"history.db",
"isFile":true,
"isDirectory":false},
{
"uri":"content://com.android.externalstorage.documents/tree/primary/FreeTube/playlists.db",
"fileName":"playlists.db",
"isFile":true,
"isDirectory":false},
{
"uri":"content://com.android.externalstorage.documents/tree/primary/FreeTube/profiles.db",
"fileName":"profiles.db",
"isFile":true,
"isDirectory":false}
]
} |
The uris look correct as is. I realise there is url encoding inside of them, but afaik, that is normal. The base tree uri isn't url encoded, but everything underneath it is. What I am suspecting may be the issue is that the permission to access that uri isn't persisting, but I can't say for sure without logs. For that, you would have to download the nightly, connect to a pc with chromium and go to, |
Sorry for the late reply. I have now installed the latest nightly I could find (freetube-0.21.1-nightly-481-Android.apk). The issue does not seem to persist here (also after reboot), while it does so on the latest beta release (0.21.1.119. On the beta release I can reproduce this by just closing the app (swipe up and remove app). On the nightly this does not reproduce the issue. As for inspecting the webview - what am I looking for in particular? I can't seem to see any device showing up. |
can confirm this bug for 0.21.3.122 too |
I was using a nightly build since my last comment and this issue was gone, until I recently updated from freetube-0.21.2-nightly-490 to freetube-0.21.3-nightly-500. Now it occurs again, in the same was as before. |
Persists on 0.22.0-nightly-504. |
Persists on 0.22.1-nightly-532. |
Is there any way u can post a screenshot of the console log after reproducing the issue? (🤞hopefully the logging i just added should help identify the core issue) |
if u r on nightly, (depending on if its working bc sometimes it breaks), there is a console log viewer under ("..." More) |
I am getting a lot of these warnings in the console log. Don't think they are related, as they also show after resetting the data directory. I might have imagined it, but I think I saw something red the instant I opened it. However, I was unable to scroll up fast enough. Is the log printed to a file I can inspect? One thing I am not sure I have mentioned before: the splash screen when opening the app adheres to my theming in the settings.db file. Then it revert to default. |
I just pushed changes which should add a |
I've tried nightly-541 now, and I can't seem to find From what I can tell, there are two errors (in red) that are raised at the start of the console log. I used screen record to capture the frame, and I got one whole and half of the first one: Not sure if those are any helpful. |
That error message (the threadPoolExecutor one) actually does look related, but I can't see most of it. |
I may have recreated this issue. |
That being said, can you try fully uninstalling and reinstalling the app? |
I was unable to get any closer to getting the full error message unfortunately. However, after your last comment I did try to first reset the data folder and then set it to the preferred location (instead of just setting the location again). That seems to work now. I could have sworn I have tried this, but apparently not... |
Guidelines
Describe the bug
Expected Behavior
The database-files should automatically be loaded upon start.
Issue Labels
feature stopped working
FreeTube Version
v0.20.0.116 (from IzzyOnDroid)
Operating System Version
Android 14 (CalyxOS)
Installation Method
.apk
Primary API used
Local API
Last Known Working FreeTube Version (If Any)
It worked prior to latest update.
Additional Information
Since I use SyncThing to sync databases across devices, I had the unfortunate experience of overwriting the databases on all devices when having the "Copy data files when moving directories" toggled on. I manage to salvage the data, and have since turned on version control on SyncThing... :)
Nightly Build
The text was updated successfully, but these errors were encountered: