Skip to content

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

  1. 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

  1. 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

  1. 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
  1. 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
  1. 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

  1. Allow some concurrency in the parse API
  2. 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.

Edited by Nicolas Pomepuy