1. 27 Aug, 2020 1 commit
  2. 19 Sep, 2019 1 commit
    • Hugo Beauzée-Luyssen's avatar
      preparser: Fix potential use after free · 49f41654
      Hugo Beauzée-Luyssen authored
      If the art fetcher completes before ReqHold gets called, we will end up
      releasing the request before holding it for the art fetcher, causing a
      use after free when the task gets released by the background worker
      invokes TerminateTask
  3. 26 Aug, 2019 2 commits
    • Thomas Guillem's avatar
      preparser: merge item locks · 5ca9d7ea
      Thomas Guillem authored
      Since input_preparser_Push() is necessarilly called from vlc_MetadataRequest().
    • Thomas Guillem's avatar
      prepaser: change options handling · b063dca4
      Thomas Guillem authored
      Reminder of the current behavior: the meta fetcher is either always triggered
      after the preparser is finished or manually.
      This commit aims to give more controls so that the meta fetcher is not
      necessarily triggered after a preparsng.
      The current behavior of macOS/playlist/mediatree is unchanged (the components
      touching the preparser).
      Here are the API changes for
       - Can't be called without a valid META_REQUEST_OPTION_SCOPE_* flag
       - The flag META_REQUEST_OPTION_SCOPE_* is not fetching meta anymore. Use
         the preparsing ends.
       - Can't be called without a valid META_REQUEST_OPTION_FETCH_* flag.
       - The META_REQUEST_OPTION_FETCH_NETWORK flag will now only fetch meta via
       - The flag libvlc_media_parse_* is not fetching meta anymore. Use
         libvlc_media_fetch_* to fetch meta when the preparsing...
  4. 06 Jun, 2019 1 commit
  5. 03 Jun, 2019 1 commit
  6. 17 Jan, 2019 1 commit
  7. 19 Sep, 2018 1 commit
  8. 31 Aug, 2018 1 commit
  9. 20 Aug, 2018 6 commits
    • Romain Vimont's avatar
      input: remove triggering of legacy events · 1bd67301
      Romain Vimont authored
      Now that the code has been adapted to receive "subtree added" and
      "preparse ended" events from the input thread and preparser callbacks,
      do not trigger the events on the input item anymore.
    • Romain Vimont's avatar
      preparser: use fetcher callbacks · 5fe63eb3
      Romain Vimont authored
      After a preparsing, the preparser may request to fetch art, and trigger
      the "preparse end" event only after the art have been fetched.
      For that purpose, the fetcher and the preparser were highly coupled: the
      fetcher was aware of a "preparse status", and was responsible to notify
      "preparse ended" on the input item when necessary.
      In order to make the fetcher more independant of the preparser, make the
      preparser trigger the "preparse ended" event when it is notified of the
      "fetch ended" event.
      This also paves the way to remove preparsing events on the input item
    • Romain Vimont's avatar
      fetcher: provide events in callbacks · 7725b102
      Romain Vimont authored
      Notify "fetch ended" in callbacks.
      This will allow to move the "preparse ended" trigger from the fetcher to
      the preparser, and make the fetcher more independant.
    • Romain Vimont's avatar
      preparser: provide events in callbacks · 81257945
      Romain Vimont authored
      The input thread used by the preparser is not exposed to the caller.
      Add a "callbacks" parameter to receive preparsing events.
    • Romain Vimont's avatar
      misc: background_worker: make the background worker multithreaded · 1789d188
      Romain Vimont authored
      A way to speed up the preparsing consists in preparsing several inputs
      in parallel.
      For this purpose, make the background worker (used by the preparser and
      fetcher) execute tasks from (possibly) several threads.
      Apart from adding a new field "max_threads" in the
      background_worker_config structure, the background worker API is kept
      Two new options are added to configure the maximum number of threads
      used for preparsing and fetching:
       - preparse-threads
       - fetch-art-threads
    • Filip Roséen's avatar
      input: preparser: prepare for multithreaded background worker · 11e76362
      Filip Roséen authored and Romain Vimont's avatar Romain Vimont committed
      As there are plans to make the src/misc/background_worker
      multithreaded, the preparser must be changed in order to support
      having several tasks running in parallel.
      These changes accomplishes said goal by moving the relevant
      task related data-members from struct input_preparser_t to a new one,
      so that each task has its own state.
  10. 26 Jul, 2018 1 commit
  11. 12 Jul, 2018 4 commits
    • Thomas Guillem's avatar
      preparser: use new input event handling · 61be7f08
      Thomas Guillem authored
      Without the use of input variables.
    • Thomas Guillem's avatar
      core: first cleaning of input_thread_t variables/event · 2ef7696e
      Thomas Guillem authored
      Currently, the input_thread_t is controllable by either input_Control, specific
      functions, by variables or by the 3 previous solutions.
      The goal of this commit is to remove variables usage when it's not necessary.
      This commit doesn't remove variables that should be used to pass users settings
      (cf.  input_ConfigVarInit).
      The "intf-event" callback is replaced by the new callback
      input_thread_events_cb that pass a new event: struct vlc_input_event. There can
      be only one listener: the creator of the input_thread_t. In the future, the new
      vlc input controller will receive these events and forward them to all
      In the meantime, I added input_LegacyVarInit, input_LegacyVarStop, and
      input_LegacyEvents, 3 helpers functions that reproduce the legacy variable
      behavior (transform new vlc_input_event to old intf-event events). These 3
      functions are meant to be removed for 4.0 release (when vlc input controller is
      For now, the playlist, the media_player, VLM and modules still use the legacy
    • Thomas Guillem's avatar
      preparser: fix segfault if input_Start fails · e86e9e59
      Thomas Guillem authored
      PS: This function is very unlikely to fail (only if vlc_clone fails).
    • Thomas Guillem's avatar
  12. 02 Jul, 2018 1 commit
  13. 07 May, 2018 1 commit
  14. 01 Jun, 2017 1 commit
  15. 29 Mar, 2017 3 commits
    • Filip Roséen's avatar
      preparser: post-pone event until after art fetching is complete · 5e6e0a66
      Filip Roséen authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      Since one can request art to be fetched through
      libvlc_media_parse_with_options, one would expect the event
      originating from this request to be sent upon the completion of all
      requested operations (not just the preparsing). The alternative would
      be to monitor the libvlc_MediaMetaChanged, hoping for an artwork URL
      change, but this can't account for error nor timeout.
      The changes introduced were written after a discussion with Hugo
      Beauzée-Luyssen where he expressed that he would, if possible, be able to
      post-pone the preparsing events until the art fetching is complete.
      Post-poning the event fixes issues that are currently reproducible where
      medialibrary is used, and art is missing (because it listens to the preparse
      event in order to generate the database contents).
      It can be viewed as a follow-up to the below rejected patch (with the
      same goal in mind):
       - https://patches.videolan.org/patch/15810/
      Signed-off-by: Hugo Beauzée-Luyssen's avatarHugo Beauzée-Luyssen <hugo@beauzee.fr>
    • Filip Roséen's avatar
      playlist: fix deadlock on destruction while preparser adds items to playlist · befb82c2
      Filip Roséen authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      As we can have incoming requests to the preparser while we are
      destroying libvlc, we can end up in a deadlock while we are removing
      all playlist_item_t from the playlist, while an item being preparsed
      tries to add additional items to the list.
      These changes fixes the issue by introducing a preparser-deactivation
      function, that will make sure that we:
       1) clear out any pending preparsing requests
       2) cancel the current item preparsing (blocking)
       3) prevent further requests to the preparser
      fixes: #18151
      Signed-off-by: Hugo Beauzée-Luyssen's avatarHugo Beauzée-Luyssen <hugo@beauzee.fr>
    • Filip Roséen's avatar
      playlist/preparser: refactor · 5c42881e
      Filip Roséen authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      This refactoring should not only allow for easier maintenance as the
      code size has shrunk, it also implements a few advantages over the
      previous implementation:
       - playlist_preparser_Cancel is now optionally blocking if the
         referred to item is currently being preparsed (required in cases
         where another action would race with the preparser, such as
         playback (as preparsing and playing an entity at the same time can
         lead to duplicate items in the playlist).
       - the congestion in terms of interacting with the preparser, and the
         preparsing itself, is lower. Meaning that we will finish a queue of
         items to preparse faster than with the old implementation.
      Signed-off-by: Hugo Beauzée-Luyssen's avatarHugo Beauzée-Luyssen <hugo@beauzee.fr>
  16. 03 Feb, 2017 1 commit
  17. 08 Dec, 2016 1 commit
  18. 28 Sep, 2016 1 commit
    • Thomas Guillem's avatar
      preparser: fix races · f3abad2d
      Thomas Guillem authored
      Fix a race between InputEvent() and input_Start(), and when cancelling a
      request that is not started by input_Start() yet.
      Thanks to Filip for pointing me out these issues.
  19. 27 Sep, 2016 2 commits
  20. 07 Jun, 2016 1 commit
  21. 05 Jun, 2016 5 commits
  22. 17 Apr, 2016 3 commits