The VideoLAN Forums

With 3.5.1 nightly of 2022-08-11 on a Samsung J7 with Android 8, viewing the complete list of TRACKS (2898 of them, all on microSD) and in continuous play with shuffle, every 5 seconds I see a growing opaque circle underneath the word TRACKS (partly occluding the top entry), like you'd get when refreshing. It doesn't remain for long enough to grow a curved arrow symbol, but vanishes.

Edit: Also occurs on Samsung J3 with Android 9, 500 tracks in internal memory. Also occurs on both phones when playing a single audio, and occurs even when top pane retreats off the screen.

Could you please share a screencast? I am not able to reproduce.

OK, now see https://rfobasic.miraheze.org/wiki/File ... oddity.png

Phantom "refresh" indicator momentarily occludes the first entry's album name, "A Night on the Town"

Do you still reproduce with the last nightly?

Still happens every 5 sec with 2022-08-30 on this 2018 phone.

Unfortunately, I am not able to reproduce. Could you please share some logs? Reproduce the issue and then go to: Settings > Advanced > Debug logs. Then share the logs with the sharing service you prefer (Google Drive, Dropbox, pastebin...).

I see no such setting in the 2022-08-30 nightly.

Damn you're right! Debug logs are disabled in debug builds.

I have to build a release build today to debug something else. I'll let you know so you can give some logs.

In the meantime, can you determine if the refresh code is being activated periodically (every 5 sec, for me) without user request?

If this is intentional, it should not give an indication on the screen in cases where there is no work to do.

In fact, now that refresh has a progress bar, the round indication isn't needed at all.

I just debugged it and yes, we periodically (every 5 seconds) update the progress of the current media to make sure it's not lost. It triggers a save in the medialibrary which then sends a callback to the UI saying something changed (and then triggering a list refresh).

There is a 300ms secure check on this to prevent displaying anything if the refresh takes less than 300ms. If I disable it (or set it to 50ms), I am able to reproduce your exact issue. On my (brand new) Pixel 6a, it takes around 70ms to finish, but it seems that your device is slow enough to let the 300ms timer exhaust every time.

As for now it's not really easy to get logs from a nightly version, can I add some logs and give you a custom release build for you to test?

Also, do you know how many tracks are indexed in your device?

EDIT : nevermind, it should be capped to 500 medias.

What should be capped? Yes, I have more than 500 tracks on each device, see first post; actually 509 on the slower one.

Custom build and logs should not be necessary as you've figured out what's going on. The only question is whether this is something you wish to fix. To me, it's a bug to have a periodic screen indication that conveys no information. Someone must agree as there's the 300ms threshold. This threshold might be adjusted heuristically by how many tracks there are or how long recent scans have taken.

OK, per your offline instructions, I've uninstalled the VLC nightly and installed your test build. First thing I have to do is select my desired folders, the 30 folders under Music. (I select these folders individually because I still believe the only way to get VLC to see new files is: deselect - add files - select.) As I select the check boxes and scroll the screen, I find that the boxes scrolled off the screen are de-selected. Eventually, discovery fails.

PS—After typing this, I go back into VLC and only then get a pop-up that VLC sees the microSD where the music is. I repeat the process and finally get status reports at the bottom of the screen.

I now have a logcat file, 2.25 Mb, don't think Pastebin will take it. Refreshes seem to take 400-600 msec, if I'm reading it correctly. Also says D/libdsm is trying to send a "netbios packet to 255.255.255.255", trying to do something with MusicBrainz, and trying to get my geolocation though I've disabled Day/Night mode.

(I select these folders individually because I still believe the only way to get VLC to see new files is: deselect - add files - select.)

New files should always be discovered upon scanning. It will be done automatically at app startup if you didn't disable the "Auto rescan" setting, or you can launch it manually by using the refresh menu.

As I select the check boxes and scroll the screen, I find that the boxes scrolled off the screen are de-selected. Eventually, discovery fails.

I am not able to replicate the issue. Neither the scroll/unchecked checkboxes one, not the discovery one. The logs may be useful for that.

Refreshes seem to take 400-600 msec, if I'm reading it correctly.

Even if you don't share the complete log, I really need all the lines containing the words "Refreshing launched". You can also lighten your log file by clearing the logs, go back to the "Audio tab", launch a music playback for one minute or so and then dump the logs.

Also says D/libdsm is trying to send a "netbios packet to 255.255.255.255"

It's not my domain of expertise but iirc, it's just trying to find some external devices to cast your media (a Chromecast device for example).

trying to do something with MusicBrainz

Could you please share the line?

and trying to get my geolocation though I've disabled Day/Night mode

The app doesn't have the geolocation permission so it won't. But can you share the line stating that?

Thanks, I have a smaller log just during playback at https://pastebin.com/tDRx7MqG

Thanks a lot. So you're right, the task takes around 600ms on your device. I'll see what I can do for that.

Thanks! But I bet that, if I pry the microSD out of my J7 and stick it in my J3, the task will be even slower! The problem should not be "tweak constants so it works on a J7" but to make it work sensibly. A task that does behind-the-scenes sanity-checking should be invisible.

Yes, that was my conclusion. 600ms is already a lot and I cannot increase this threshold indefinitely.

Now, here is the sequence that references MusicBrainz, and even Google. Is it trying to find album art on the web? But it seems it didn't go through with it.

09-07 21:25:08.154 D/VLC (24158): [be37c530/c483a0a0] libvlc libvlc: plug-ins loaded: 370 modules
09-07 21:25:08.154 D/VLC (24158): [bf4af1f0/2d6e6f2d] libvlc logger: looking for logger module matching "any": 4 candidates
09-07 21:25:08.154 D/VLC (24158): [bf4af1f0/692d6e6f] libvlc logger: using logger module "android_logger"
09-07 21:25:08.154 D/VLC (24158): [be37c530/5e5e] libvlc libvlc: translation test: code is "C"
09-07 21:25:08.154 D/VLC (24158): [bf4af2b0/5e5e] libvlc keystore: looking for keystore module matching "memory": 3 candidates
09-07 21:25:08.154 D/VLC (24158): [bf4af2b0/5e5e] libvlc keystore: using keystore module "memory"
09-07 21:25:08.154 D/VLC (24158): [be37c530/5e5e] libvlc libvlc: CPU has capabilities ARM_NEON FPU
09-07 21:25:08.156 D/VLC (24158): [bf4f6230/5e5e] libvlc playlist: creating audio output
09-07 21:25:08.156 D/VLC (24158): [bf2992b0/5e5e] libvlc audio output: looking for audio output module matching "android_audiotrack": 4 candidates
09-07 21:25:08.156 D/VLC (24158): [bf2992b0/5e5e] libvlc audio output: using audio output module "android_audiotrack"
09-07 21:25:08.156 D/VLC (24158): [bf4f6230/5e5e] libvlc playlist: keeping audio output
09-07 21:25:08.157 D/VLC (24158): [be36c830/5eda] libvlc input: Creating an input for preparsing 'soxr'
...
09-07 21:25:08.159 E/VLC (24158): [bf192af0/5edb] libvlc stream: cannot open file //soxr (No such file or directory)
09-07 21:25:08.159 D/VLC (24158): [bf192af0/5edb] libvlc stream: no access modules matched
09-07 21:25:08.159 E/VLC (24158): [be36c830/5edb] libvlc input: Your input can't be opened
09-07 21:25:08.159 E/VLC (24158): [be36c830/5edb] libvlc input: VLC is unable to open the MRL 'file:////soxr'. Check the log for details.
09-07 21:25:08.159 D/VLC (24158): [be36c830/5eda] libvlc input: Destroying the input for 'soxr'
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc meta fetcher: looking for meta fetcher module matching "any": 1 candidates
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc meta fetcher: Trying Lua scripts in /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/fetcher
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc meta fetcher: Trying Lua scripts in /data/app/org.videolan.vlc.debug-VnOpBBBK_Ktgc84MeAnxBA==/lib/arm/vlc/lua/meta/fetcher
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc meta fetcher: Trying Lua scripts in /system/usr/share/lua/meta/fetcher
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc meta fetcher: no meta fetcher modules matched
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc art finder: looking for art finder module matching "any": 2 candidates
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua scripts in /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art
09-07 21:25:08.160 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua playlist script /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/00_musicbrainz.lua
09-07 21:25:08.161 D/VLC (24158): [ddb46180/5edd] libvlc art finder: skipping script (unmatched scope) /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/00_musicbrainz.lua
09-07 21:25:08.162 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua playlist script /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/01_googleimage.lua
09-07 21:25:08.162 D/VLC (24158): [ddb46180/5edd] libvlc art finder: skipping script (unmatched scope) /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/01_googleimage.lua
09-07 21:25:08.163 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua playlist script /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/02_frenchtv.lua
09-07 21:25:08.163 D/VLC (24158): [ddb46180/5edd] libvlc art finder: skipping script (unmatched scope) /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/02_frenchtv.lua
09-07 21:25:08.164 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua playlist script /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/03_lastfm.lua
09-07 21:25:08.164 D/VLC (24158): [ddb46180/5edd] libvlc art finder: skipping script (unmatched scope) /data/user/0/org.videolan.vlc.debug/app_vlc/.share/lua/meta/art/03_lastfm.lua
09-07 21:25:08.165 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua scripts in /data/app/org.videolan.vlc.debug-VnOpBBBK_Ktgc84MeAnxBA==/lib/arm/vlc/lua/meta/art
09-07 21:25:08.165 D/VLC (24158): [ddb46180/5edd] libvlc art finder: Trying Lua scripts in /system/usr/share/lua/meta/art
09-07 21:25:08.165 D/VLC (24158): [ddb46180/5edd] libvlc art finder: no art finder modules matched

The app doesn't have the geolocation permission so it won't. But can you share the line stating that?

This is my mistake. I had Day/Night set, turned it off, and was startled to see in the log that VLC was still asking for my geolocation. (It never got it, as indeed I didn't give it the permission.) But now it no longer does so. The change to configuration didn't take effect until VLC was killed and restarted.

About the musicbrainz / googleimage lua scripts: from what I see, the goal of these scripts are to retrieve tracks/streams thumbnails. In that case I am not sure they are used at all. I'll ask people knowing more on that part than me.

About the geolocation part: if you still have your first logs, I'd be interested in getting the exact logs talking about geolocation to understand what is happening.

I don't have the original logs, but re-enabled Day/Night Mode, restarted, and saw messages from I/TwilightManager: "Could not get last known location. This is probably because the app does not have any location permissions. Falling back to hardcoded sunrise/sunset values." It was startling that VLC seemed to want to know my location! Doesn't Android make this calculation and provide day/night status to apps?

If you go to Settings > Interface > DayNight mode, your setting is set to "DayNight mode", right? As your devices seem to use old Android versions, this is the only setting that remains besides "Light theme" or "Dark theme".

Here is the documentation of this feature:https://developer.android.com/reference ... _AUTO_TIME()
As you can see, it needs the location to determine the sunset and sunrise time. But as VLC doesn't have the location permission, it falls back to hardcoded values. You can see the exact code here: https://android.googlesource.com/platfo ... er.java#94

Now, this is clever, I guess! Running released 3.5.2 (2022-09-19) on my slow device with 2898 tracks, and enabling the "Show layout boundaries" developer option, I see the element being created and destroyed almost every 5-second interval. But it has been made transparent. With the option disabled, there is no hint of it.