1. 02 May, 2016 3 commits
  2. 28 Apr, 2016 2 commits
  3. 19 Apr, 2016 5 commits
  4. 17 Apr, 2016 2 commits
  5. 08 Apr, 2016 1 commit
  6. 07 Apr, 2016 2 commits
  7. 06 Apr, 2016 1 commit
  8. 05 Apr, 2016 4 commits
  9. 04 Apr, 2016 1 commit
    • Benjamin Adolphi's avatar
      Fixed bug where the VLCMedia server browser in some cases would play a folder instead of opening it · dd68214b
      Benjamin Adolphi authored
      In some cases, when navigating through folders using the VLCMedia server browser, VLC would try to play the folder instead of listing its contents. One way to reproduce this is to browse the content of a folder, then go back the the parent folder, then browse the content of the same folder again and then browse the content of a sub-folder.
      The problem is in the _addMediaListRootItemsToList method of the VLCMedia server browser. This method makes a copy of the all the media in a folder. The copied media is then used to create VLCNetworkServerBrowserItemVLCMedia objects that are appended to the mutableItems list. When creating a new VLCNetworkServerBrowserItemVLCMedia, the initWithMedia:options: method decides whether the item is a folder or not based on the media type of the media. However, the copied media always has the 'VLCMediaTypeFile' type even when the media is a folder. This is because the input items of the original media objects are created in libvlc when the content of a folder is parsed and there, the type is set correctly. But when making a copy the way _addMediaListRootItemsToList does, libvlc will just set 'VLCMediaTypeFile' as the type of the input item of the media.
      This bug was actually mostly fixed by accident already (in f1bf1413). In that commit, the original media is used to create the VLCNetworkServerBrowserItemVLCMedia objects instead of the copied one. Since the copying of media is not needed anymore, we can simply remove it completely and use the code from the accidential fix, which uses the original media.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
  10. 21 Mar, 2016 1 commit
    • Benjamin Adolphi's avatar
      tvOS: Fixed bug when restoring the focused cell in the server browsing view · af3c735d
      Benjamin Adolphi authored
      When the collection view of the server browsing view controller is appearing, it will in some cases try to reload its data. If this happens depends on the server browser implementation. Some server browsers will trigger an update (VLCMedia, Plex, UPnP and HTTP) and some won't (FTP). When this happens, all the cells in the collection view are being recycled and the view is repopulated with cells. After that, the tvOS focus engine will give focus to the collection view, which will then restore the previously selected cell. Unfortunately, this is implemented by Apple in such a way that the focus engine will pass the cell to select to the UICollectionView class, which will then select the same cell again. The problem here is that the cell recycling mechanism does not guarantee that the same cell is used for the same thing. This usually leads to the selection of the wrong cell when the view comes back into the foreground and an update was triggered.
      I my opinion, this is an Apple bug. The UICollectionView class should be able to select the correct cell after its data has been reloaded. But since this is the current situation, we need to work around the problem to fix the issue. One way to do this would be to do the same thing as the FTP server browser and not update when the view reappears. However, this decreases flexibility and causes a dependency of the the server browsers on UI problems.
      Another way to solve this is to use the tvOS focus engine. The idea is to select the correct cell ourselves whenever the collection view is gaining focus. In addition, we prevent the wrong selection of the cell that the UICollectionView class wants to select by telling the focus engine that only the cell we want to switch to is focusable during the time when the collection view gains focus. This commit implements that approach.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
  11. 08 Mar, 2016 2 commits
  12. 07 Mar, 2016 2 commits
    • Benjamin Adolphi's avatar
      URL decode name in VLCNetworkServerBrowserItemVLCMedia · 31bb1d69
      Benjamin Adolphi authored
      In order to determine its name, a VLCNetworkServerBrowserItemVLCMedia will first check if its media has been parsed and use the parsed title information if it has been. If it hasn't been parsed, it will fallback to the filename of the media and if that doesn't work, the whole path of the media. The filename and path of media are URL encoded (at least in the case where the media is located on an SMB share). This commit adds decoding of the URL encoded values when setting the name of a VLCNetworkServerBrowserItemVLCMedia.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
    • Benjamin Adolphi's avatar
      Do not filter files on libvlc browsed servers in libvlc, but in the server browser · f1bf1413
      Benjamin Adolphi authored
      Currently, when listing the files in a folder that is browsed using libvlc, libvlc will filter the files in that folder to exclude files with known non-playable file extensions. This is a problem because the server browser that handles libvlc browsed servers needs to know about all files in a folder in order to be able to find subtitles in external files. This commit changes the behaviour to not filter any files in libvlc, but in the server browser instead so we are able to add support for finding external subtitle files later.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
  13. 03 Mar, 2016 6 commits
  14. 11 Feb, 2016 1 commit
    • Benjamin Adolphi's avatar
      Fixed finding of external subtitle files that are located on non libvlc browsed servers · 5088d8c1
      Benjamin Adolphi authored
      When playing a movie from a server on the local network that is not browsed with libvlc (e.g. an FTP server), subtitles that are located in an external file will not be discovered. This issue was observed on tvOS but should affect iOS as well.
      The problem seems to be that when the user selects an item, the following code is executed in the VLCNetworkServerBrowserViewController/VLCServerBrowsingTVViewController (if not in single playback mode):
      VLCMediaList *mediaList = self.serverBrowser.mediaList;
      [self.browsingController configureSubtitlesInMediaList:mediaList];
      [self.browsingController streamMediaList:mediaList startingAtIndex:index];
      This code tries to find and configure the subtitles for all of the entries in the mediaList. However, at the time when configureSubtitlesInMediaList is called, the mediaList is always empty, so no subtitles are being configured.
      The reason for the mediaList being empty is a timing issue. When the mediaList is retrieved from the responsible serverBrowser, it will create a new VLCMediaList from its items and add them to the list using the addMedia method. The problem here is that the addMedia method is adding the items to the list asynchronously on the main thread. Since the code that retrieves the list and then searches for the subtitles also runs on the main thread, the items will only be added after that code is finished.
      This commit solves the problem by having the server browser classes that do not use libvlc to discover media not create the media list when the list is requested but already when the browser has found out which files are in the current location.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
  15. 08 Feb, 2016 2 commits
  16. 04 Feb, 2016 3 commits
  17. 28 Jan, 2016 2 commits