Clear media database : on-boarding should be relaunch after this action

Description

The Clear Media Database action in the settings (Settings > Advanced) is useful because it clears all the medialibrary, keeping all the settings defined by the user.

But :

• No information is displayed to the user to confirm the success
• you have to restart the app manually and no default folders are selected for the medialibrary so that can be confusing for users

Expected behavior

After the action, we should restart the app and launch the on-boarding.

Moreover, we should have a direct access to this Android Clear Data view, as we had some time ago :

This is available from the Android Info app view but it's sometimes hard for a user to access it, depending of your Android Retailer version (it's very hard with a huawei phone for example)

changed milestone to %3.4.x

added feature label

What about opening the "Media library folders" instead of the onboarding?

I took a (loooong) look and relaunching the onboarding is painfuland seems weird. As the only missing information is the directories to scan.

I feel that opening the "Media library folders" screen is better.

I thought that onboarding was the easiest way to select the default foders, that's why I suggested this.

I'm not convinced about opening the media library folders, because it's intimidating for most of the people : they will probably select all Internal Device or will be afraid of doing anything...

A alternative could be open Media library folders WITH the default folders already selected.

But maybe there is still an issue with external devices ? (SD card...)

After more discussion, we decided:

• By default, on first launch, the app should discover only the internal subfolders (Music, Movies, Podcasts, ...)
• When clearing the media database, these same folders should be added back
• We should add a setting allowing the user to go to the system "clear data"

EDIT: by default, we want to discover the whole internal storage to avoid changing this behavior.

mentioned in merge request !995 (merged)

Maybe thumbnails cache should also be cleared ? it may be almost fine after rescan when thumbnails files have media name, but when it's an id.jpg, if it's not the same id, thumbnails are all wrong.

Also when a media is removed from the db (either delete from the app or media not there anymore when scanning), thumbnails files are kept. maybe there should be a cleanup of thumbnails files not in the db anymore after a scan ?

Maybe thumbnails cache should also be cleared ?

Yes! Nice catch.

Also when a media is removed from the db (either delete from the app or media not there anymore when scanning), thumbnails files are kept. maybe there should be a cleanup of thumbnails files not in the db anymore after a scan ?

If you have reproduction steps, it would be nice to create a new issue. The medialibrary should already delete the unnecessary thumbnails.

Just tested again, it doesn't delete anything, maybe i'm doing something wrong ?

• put an mp4 in the folder, a jpg is generated in medialib/thumbnails after scan
• remove the file from the folder, scan, the video is not visible in vlc => jpg is still there
• put the mp4 again, it reappear in vlc, delete it from inside vlc => jpg is still there

maybe because the folder in on the sdcard, not in internal memory ?

PS: i just discovered that some are generated in medialib/thumbnails/.jpg, some other are in medialib/.jpg. even if they are episodes of the same show (so similar encoding and everything).

Generating/deleting the thumbnails is delegated to the medialibrary. As you saw, some thumbs are under /medialib (named with a filename) others under /medialib/thumbnails (named with an id). The first kind is because when looking for a video thumbnail, we first ask Android to get a thumb and, if we find one, we don't ask for it to the medialibrary. It allows VLC for Android to have less black thumbs that other ports.

I tested the deletion as well and it works great... for thumbs generated by the medialibrary: if the media is removed from indexed folders or the file is deleted, the thumb file is removed.

However, it doesn't work for thumbs generated by the app it self. I'll take a look.

cool, thank you

FYI, this issue is now tracked here: #2049 (closed)

mentioned in issue #2049 (closed)

I noticed during development that artwork is actually stored separately by medialibrary and libVLC. The two paths are:

1. /data/user/0/org.videolan.vlc.debug/app_vlc/.cache/art/artistalbum
2. /storage/emulated/0/Android/data/org.videolan.vlc.debug/files/medialib/thumbnails/

Android seems to have two predefined paths which are wired to the Clear Data and Clear Cache buttons, respectively.

1. /data/user/0/org.videolan.vlc.debug/
2. /data/user/0/org.videolan.vlc.debug/cache

After some research, I determined the app_vlc path appears to be passed as the HOME environment variable at: https://code.videolan.org/videolan/vlc-android/-/blob/master/libvlc/src/org/videolan/libvlc/LibVLC.java#L83

The .cache folder is appended at https://code.videolan.org/videolan/vlc/-/blob/master/src/android/specific.c#L281

Given the desire to be able to use the Clear Data and Clear Cache buttons, wouldn't it be preferable to pass the Context.getCacheDir() to libVLC? I suppose it could be equivalent to passing /data/user/0/org.videolan.vlc.debug/ as HOME and appending cache? (It's probably a best-practice to use the API instead of reconstructing the path to the cache, but is certainly more work at this point.) Ultimately, I think the objective should be to relocate /data/user/0/org.videolan.vlc.debug/app_vlc/.cache/art/ to /data/user/0/org.videolan.vlc.debug/cache/libvlc/art to match the Android directory structure.

Thoughts?

I tried to apply your suggestion and indeed, using context.getCacheDir() allows the clear cache system setting to clear the artworks.

However, this folder also contains other files and I am not really sure if it's possible to clear them without any issue.

FFR here is the list of the files I found:

cache_files.txt

Maybe @tguillem or @alexandre-janniaux could help?

closed with commit 73d398a1