VLC file parsing synchronicity leads to multiple UI issues
This is a meta issue listing all the issues in VLC Android that are caused by vlc's file parsing design.
Current implementation
To request a file/network parsing, the app calls libvlc's MediaBrowser::browse(...)
method with calls IMedia::parseAsync(...)
internally. This call is synchronous and any further call will be locked while the first one is not finished or timed out.
Problem caused in VLC Android by this limitation
- Slow network
When user's network is slow (low wifi for example), the network share discovery call is blocking the app's browser.
graph TD
A[App launch] --> B[Open the Browse tab]
B --> C[Automatic start of network discovery]
C -.->|Slow wifi| D[Parsing locked]
B --> E[User tries to open a folder]
D -.-> F[After a really long time, task finished]
E -.-> |Waits for| F
F --> G[Folder parsing can start]
See #2235
- ML blocking the app browser
Following the exact same workflow, a medialibrary parsing can block VLC Android's browser. It happens when a folder has many files/folders in it and it takes some time to parse it. During that time, the browsing is locked in-app.
graph TD
A[App launch] --> B[Open the Browse tab]
A --> C[ML discovery start]
C -.->|Large folder on slow SMB drive| D[Parsing locked]
B --> E[User tries to open a folder]
D -.-> F[After a really long time, task finished]
E -.-> |Waits for| F
F --> G[Folder parsing can start]
It's relatively easy to reproduce by making the ML index a large SMB folder and should be even more noticeable with a slow SMB drive and a slow connection.
Possible mitigations
- Use a timeout
A timeout can be set on the IMedia::parseAsync()
call. But
- it would only mitigate the "slow network" issue as we have no power on the calls made by the medialibrary
- it would be a poor mitigation as the user would have to wait for the timeout to start browsing
- Make the
IMedia::parseAsync()
cancelable
Pros:
- easy to implement (@tguillem said it's 3 lines away)
- the app can cancel all the calls from the root (especially the network share discover) when the user starts browsing
Cons:
- it only mitigates the issues from the calls made by the app, not ML's ones
- Call the ML pause API when starting the browsing
Pros:
- the browsing is not blocked by the ML
Cons:
- we have to make sure that the ML pause API effectively cancels the current folder discovery or else, it solves nothing (See medialibrary#466)
Proper solutions
- Allow some concurrency in the parse API
- Use multiple instances of vlc to do these different tasks.
Unfortunately, for now it's not possible as the keystore cannot be shared between multiple instances.