Jeremy Gollehon Posted October 18, 2016 Share Posted October 18, 2016 When Emby deletes a file there is a 5+ second delay before the entry in Kodi is removed. This throws off anybody who doesn't understand they're waiting for the file to actually be deleted and a response to come back from the server. A better user experience would be to delete the Kodi entry immediately and let the user go on their way while Emby does it's thing in the background. Thoughts? Link to comment Share on other sites More sharing options...
Angelblue05 Posted October 19, 2016 Share Posted October 19, 2016 Not at this time. I will try to think of a solution. Right now, the add-on sends the delete action to the server, when it's processed, the server generates the usual websocket event which trigger the deletion in Kodi. Link to comment Share on other sites More sharing options...
Jeremy Gollehon Posted October 19, 2016 Author Share Posted October 19, 2016 Cool. Thanks for the consideration. Would it mess up the sync if you deleted the Kodi db entry first, then sent the delete to Emby? Or do you guys not touch Kodi directly? Link to comment Share on other sites More sharing options...
Angelblue05 Posted October 19, 2016 Share Posted October 19, 2016 The add-on doesn't touch Kodi directly. Because it would cause a double delete action. Also, what if the user is not allowed to delete items... Then you'd end up with missing entries and you'd need to run a manual sync to re-add the missing entry in Kodi. I think a visual queue the action was done would be a good compromise... like "delete queued for {title}" Link to comment Share on other sites More sharing options...
Luke Posted October 19, 2016 Share Posted October 19, 2016 when you send the delete http request you can also just wait for it if you want. Link to comment Share on other sites More sharing options...
Angelblue05 Posted October 19, 2016 Share Posted October 19, 2016 when you send the delete http request you can also just wait for it if you want. what do you mean? We already send the delete HTTP request and wait for the websocket to trigger the delete within Kodi. Link to comment Share on other sites More sharing options...
Luke Posted October 19, 2016 Share Posted October 19, 2016 when the delete http request completes you can assume the deletion is complete, so if you wanted to block the UI while this is happening, you could. Link to comment Share on other sites More sharing options...
xnappo Posted October 19, 2016 Share Posted October 19, 2016 Yeah, I was thinking the same thing. We could throw up a spinner until we get a response. I am not sure that is better, but we can't just delete it Kodi side before getting the response because the delete might fail. Link to comment Share on other sites More sharing options...
Jeremy Gollehon Posted October 19, 2016 Author Share Posted October 19, 2016 Throwing up a spinner would probably be a worse user experience. At least now you can navigate around. It's just a little weird when the show disappears "randomly" sometime after the delete. If you delete it Kodi side, wouldn't the "error state", meaning the show wasn't deleted Emby side just result in the show being added back to the Kodi db? What happens right now when a show can't be deleted? What if you deleted Kodi side, then, if it can't be deleted Emby side just throw up the same error message/ux that happens now when it can't be deleted. Link to comment Share on other sites More sharing options...
Angelblue05 Posted October 19, 2016 Share Posted October 19, 2016 (edited) Right now, if there's an error server side, then it just won't delete Kodi side. There's no notification of sort that informs you. I still think a notification of queued action will be good enough. It tells the user the action has been sent, so it will be processed. I don't want to block the UI, unless really necessary. I'm currently working on a notification system for the add-on (which is needed for other parts of the code). Edited October 19, 2016 by Angelblue05 1 Link to comment Share on other sites More sharing options...
Recommended Posts