1. 26 Jul, 2018 1 commit
  2. 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
  3. 02 Jul, 2018 1 commit
  4. 07 May, 2018 1 commit
  5. 01 Jun, 2017 1 commit
  6. 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
  7. 03 Feb, 2017 1 commit
  8. 08 Dec, 2016 1 commit
  9. 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
  10. 27 Sep, 2016 2 commits
  11. 07 Jun, 2016 1 commit
  12. 05 Jun, 2016 5 commits
  13. 17 Apr, 2016 3 commits
  14. 28 Oct, 2015 2 commits
  15. 25 Mar, 2015 2 commits
  16. 04 Feb, 2015 1 commit
  17. 13 Jan, 2015 1 commit
  18. 19 May, 2014 3 commits
  19. 31 Dec, 2013 2 commits
  20. 21 Aug, 2012 1 commit
  21. 16 Feb, 2012 1 commit
  22. 15 Dec, 2011 1 commit
  23. 29 Nov, 2011 1 commit
    • Rémi Denis-Courmont's avatar
      Remove write-only timer statistics · e3a897cf
      Rémi Denis-Courmont authored
      The implementation was slow/inefficient. This is really silly for
      _performance_ counters. And contrary to the other statistics, nothing
      actually reads them, except for debug logs.
      
      If you really want debug-only performance timers, use this:
      
          mtime_t start, end;
      
          start = mdate();
          compute_decimals_of_Pi(100);
          end = mdate();
          msg_Dbg(obj, "spent %"PRIu64" us computing", end - start);
      e3a897cf