1. 25 May, 2015 1 commit
  2. 09 May, 2015 3 commits
  3. 15 Dec, 2014 4 commits
  4. 12 Dec, 2014 2 commits
  5. 15 Aug, 2014 1 commit
  6. 11 Aug, 2014 1 commit
    • Nicholas Little's avatar
      Dap.Mtp: Improve status logging on load (bgo#734430) · 0462f352
      Nicholas Little authored
      The loading operation for MTP involves enumerating files, clearing
      empty albums, writing track information to the database and reading
      playlists. Banshee only produces a status update for the first step, in
      addition the current never reaches the total (due to an off-by-one
      issue) so it appears that the last track takes a long time to enumerate
      and load.
      This patch adds status messages for those operations so the user
      doesn't experience a long delay with the same message before being
      able to use his device. In addition, we move the calls to
      Catalog.GetString outside of their respective loop bodies as a small
      performance optimisation.
      Signed-off-by: default avatarAndrés G. Aragoneses <knocte@gmail.com>
  7. 10 Aug, 2014 1 commit
  8. 06 Aug, 2014 1 commit
  9. 04 Aug, 2014 1 commit
  10. 02 Aug, 2014 3 commits
  11. 01 Aug, 2014 4 commits
  12. 30 Jul, 2014 2 commits
  13. 28 Jul, 2014 4 commits
  14. 25 Jul, 2014 3 commits
    • Nicholas Little's avatar
      Dap: not purge at disconnect & virtualize load (bgo#732634) · ba87f8c8
      Nicholas Little authored
      For DAP sources where metadata is difficult or costly to extract
      (i.e. Bluetooth, as it's a much slower medium), it is useful to
      keep the old metadata around to allow for speedy track enumeration
      in the cases where files are still present.
      To allow for those cases this patch:
      - Adds two new virtual methods, PreLoad() and PostLoad(), which
      allow subclasses to customise behaviour at those times
      (Bluetooth extension will override PreLoad() avoiding the purge
      of tracks; and will probably add caching strategies to both
      - Removes calls to PurgeTracks() and PurgeTemporaryPlaylists()
      from the Dispose() method, which is called when the device is
      For sources that don't take advantage of this new functionality,
      this shouldn't actually result in a change of behaviour (it is
      true that the track records will not be deleted from the DB when
      the device is disconnected; but this deletion will occur when
      the device is connected again anyway, at PreLoad() via
      PurgeTracks() and at Initialize() via PurgeTemporaryPlaylists(),
      like it used to happen.)
      Signed-off-by: default avatarAndrés G. Aragoneses <knocte@gmail.com>
    • Andrés G. Aragoneses's avatar
    • Andrés G. Aragoneses's avatar
      CoverArt: display embedded artwork even if tags missing (bgo#692107) · b2f8cbb1
      Andrés G. Aragoneses authored
      Most MetadataProvider classes cannot retrieve cover art if there
      is no album name information in the track because they get retrieve
      the metadata from online sources. However, there is a provider which
      does it locally: EmbeddedMetadataProvider.
      In this case, the restriction about album name being known doesn't
      really apply, so let's move this restriction to the online providers
      and remove it from the more generic MetadataService and CoverArtJob
  15. 22 Jul, 2014 3 commits
  16. 21 Jul, 2014 1 commit
  17. 18 Jul, 2014 1 commit
  18. 17 Jul, 2014 4 commits
    • Nicholas Little's avatar
      Dap: remove unused variable in RemovableSource · 65871902
      Nicholas Little authored
      The sync variable in RemovableSource was only used in a not operation in
      the CanUnmap property. This patch removes the unused variable and marks
      the property as virtual for subclasses to override.
    • Andrés G. Aragoneses's avatar
      Logging: bring latest hyena (& kill majority of warnings from it) · 7f7a27ec
      Andrés G. Aragoneses authored
      Latest change in hyena is the deprecation of Log.Exception() methods
      because of its severity ambiguity. To fix the warnings generated by
      this deprecation, I've taken this rule of thumb:
      - If the exception being logged comes from a generic catch(Exception)
      it's probably a way to avoid that Banshee crashes, and having a generic
      Exception type (instead of a more specific one, i.e. FormatException)
      most likely means that the reason for the exception is unknown, so it's
      convenient to file this as an error. If any of this particular cases
      becomes frequent enough, we can always look at the stacktrace, and put
      a more specific catch() block that uses Log.Warning() in the future.
      - If the exception being logged comes from a specific catch block of
      a specific exception type (derived from System.Exception) it normally
      corresponds to a non-severe problem that can be ignored, but logged as
      a warning.
    • Andrés G. Aragoneses's avatar
      AmazonMp3: mark a string for translation · 9ce3a5f3
      Andrés G. Aragoneses authored
      This string is sent to the UI but was not marked for translation.
    • Andrés G. Aragoneses's avatar
      GStreamerSharp: improve previous commit to fix the build (bgo#724752) · 7615c7fd
      Andrés G. Aragoneses authored
      Previous commit [1] fixed the build for MonoDevelop in Linux, but
      could likely break the build for Windows, where we don't use pkg-config
      (we just place the dependencies in a directory). So seems like using
      <HintPath> along with <Package> element doesn't generate any conflicts.
      [1] https://git.gnome.org/browse/banshee/commit/?id=1ea5969f81f951009202e4884b01eda6ffd671f7