query filecache for media files, overwrite path with path from filecache #182
Conversation
|
@MorrisJobke I need some help with mocking searchByMime(). I toyed around with it locally, but don't seem to get how to use mocking :( |
|
Added a hack for the cover file path as well. works fine here ... still need help with mocking searchByMime() to make travis happy. |
|
@MorrisJobke now also removes tracks when unsharing them. Boy this is just getting uglier and uglier ... |
|
@MorrisJobke This PR now uses the getPath implementation from owncloud/core#7935 to resolve the paths for tracks and covers. The covers however will only show up after the user has updated the filecache (via cron or ajaxcron etc) @icewind1991 please review. |
| @@ -199,14 +199,23 @@ public function update($path, $userId = NULL){ | |||
| * Get called by 'delete' hook (file deletion) | |||
| * @param string $path the path of the file | |||
| */ | |||
| public function delete($path){ | |||
| public function deleteByPath($path){ | |||
| $metadata = $this->api->getFileInfo($path); | |||
There was a problem hiding this comment.
Can we add here the emit of the "delete" event?
$this->emit('\OCA\Music\Utility\Scanner', 'delete', array($fileId, $userId));
There was a problem hiding this comment.
feel free to change the PR to your needs
|
Once the stuff is merged into master this will be merged. @butonic @DeepDiver1975 @icewind1991 Any ideas for OC6 and OC5? |
|
I squashed all the commits into one and force pushed to remove the ugly workaround code from git :) |
* add hook handler for unshare event - deletes track on unshare * use of methods instead of key access for metadata
|
The inspection completed: 7 updated code elements |
query filecache for media files, overwrite path with path from filecache
@MorrisJobke @DeepDiver1975 Here is something to work with. This PR uses the filecache to search for audio files and overwrites the path of the track entities with the one from the filecache. A similar hack would be needed for cover art, but I wanted to get this out ASAP for discussion.
Personally, I think this is an ugly solution ... then again the sharing implementation has its deficiencies. The whole reason we have to go this route is because sharing allows sharing a folder with a single share entry, not marking all affected files as shared ... hm ... need to chew on that ...