Dev build 266

[paul777 13]

I agree - it's a difficult one, we don't want to have potentially long running server calls on the UI thread and we don't want to access the UI from other threads - we probably need a AsyncCallAndWaitWithTimeout to use to call the server. In the short term it feels safer to have server operations done from the UI thread than to risk calling the UI from other threads though.

[ebr 16169]

In the short term it feels safer to have server operations done from the UI thread than to risk calling the UI from other threads though.

 

Maybe, but I'm not positive of that.  No one was reporting an issue (other than the debugger break which was just a statement that shouldn't have been there) with it doing it the bad way it is now but invoking the operation on the main thread will almost certainly cause some people to have a "Not responding" situation if they try to interact too quickly.

 

I'll have to investigate deeper when I have the time.

[paul777 13]

I have updated the pull request with some code that does the server calls on another thread with a signalled timeout to the main thread, I haven't been able to test it as my collection is read only. Slight downside is that if it times out we can't actually kill the operation - but that is no worse than we have at the moment. Personally I don't the delete functionality so I'm not that fussed if it gets left to just log the warning and run on the wrong thread but we should be aware that it is one possible cause if people report instability.

[AgileHumor 123]

I have updated the pull request with some code that does the server calls on another thread with a signalled timeout to the main thread, I haven't been able to test it as my collection is read only. Slight downside is that if it times out we can't actually kill the operation - but that is no worse than we have at the moment. Personally I don't the delete functionality so I'm not that fussed if it gets left to just log the warning and run on the wrong thread but we should be aware that it is one possible cause if people report instability.

 

I think the most likely cause of a failure in deleting is a locked or in use file (OS indexing, etc).   Any way you can gracefully exit in that case with an error message?

[ebr 16169]

I think the most likely cause of a failure in deleting is a locked or in use file (OS indexing, etc).   Any way you can gracefully exit in that case with an error message?

 

The server is the one who does the actual delete.  MBC just requests it via the API.  That is part of what makes this process trickier than it was in MB 2.

[tp546 41]

Hey ebr, how can I roll back to the last build that the "play all from here" was working on? i changed my update level from beta to release and checked for an update, but it didn't work (i suspect this is because my version is more current than the last release build). let me know.

[BAS 225]

Hey ebr, how can I roll back to the last build that the "play all from here" was working on? i changed my update level from beta to release and checked for an update, but it didn't work (i suspect this is because my version is more current than the last release build). let me know.

 

Goto http://emby.media/download/ and get the official release.

[ebr 16169]

I can push a new beta with that fixed.

 

Edit: I actually pushed it as a dev release.

[jordy 284]

Hi ebr, just a couple of points re v265 on xbox 360.

 

1  I try to use the xbox interface via xbox controller but its too slow and i understand why no big deal.

2  I tried using the web interface/client on my android phone as a remote - its great and play videos to the end flawlessly - as long as I dont need to pause the show....

 

Pausing the show via the Remote Control interface in the web client will pause or stop the video but I cannort find a way to re-start it - no "Play" button.

 

Any suggestions or can you fix it please.

 

thanks

[ebr 16169]

266 should fix play all/shuffle.