1. 20 Aug, 2018 1 commit
    • 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.
      11e76362
  2. 26 Jul, 2018 1 commit
  3. 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.
      61be7f08
    • 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
      listeners.
      
      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
      added).
      
      For now, the playlist, the media_player, VLM and modules still use the legacy
      variables.
      2ef7696e
    • 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).
      e86e9e59
    • Thomas Guillem's avatar
      ade7b823
  4. 02 Jul, 2018 1 commit
  5. 07 May, 2018 1 commit
  6. 01 Jun, 2017 1 commit
  7. 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>
      5e6e0a66
    • 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>
      befb82c2
    • 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>
      5c42881e
  8. 03 Feb, 2017 1 commit
  9. 08 Dec, 2016 1 commit
  10. 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.
      f3abad2d
  11. 27 Sep, 2016 2 commits
  12. 07 Jun, 2016 1 commit
  13. 05 Jun, 2016 5 commits
  14. 17 Apr, 2016 3 commits
  15. 28 Oct, 2015 2 commits
  16. 25 Mar, 2015 2 commits
  17. 04 Feb, 2015 1 commit
  18. 13 Jan, 2015 1 commit
  19. 19 May, 2014 3 commits
  20. 31 Dec, 2013 2 commits
  21. 21 Aug, 2012 1 commit
  22. 16 Feb, 2012 1 commit
  23. 15 Dec, 2011 1 commit