tuning: reloading slideshow after failure

ljunkie commented 10 years ago

Do not blindly reload the slideshow after first image fails (2 failures). Need to be a little more smart on what actually failed and why if possible.. but quicker fix would be to reload only after a certain amount of failures.. not just 2.

On a reload, it's OK if we get less items than the previous, but if we have less because one or more of the chunk requests fail, then we shouldn't trust the results and try later.

These are just some examples.. more tuning than the above is needed.

sa2000a commented 10 years ago

Thanks for registering this.

I understand the reasons but would be nice if i shutdown the PMS for a long while or if I reboot it or if there is a network outage then would be nice to be able to continue with the held context - as i believe this was always the case - so if context has to be reloaded for some scenareos then need to distinguish between image related matters, Roku related issues, and server/network failures or maintenance. it is not going to be easy to detect and establish which it is but as you indicate to be tuned over time

ljunkie commented 10 years ago

In any situation where the PMS is unreachable or not responding to requests, then the this issue is moot. It would get zero results and wouldn't replace the context.

The issue you have shown is when your PMS is busy and broken. It will respond to some requests, but not all.The other fact is still true, it shouldn't try and reload after 2 failure - For one, it could just be a bad image.

ljunkie commented 10 years ago

Fact #2 it should not continue with the reload if the count is the same (checked before any chunk request). This is normally true, but was overridden due to the failure.

ljunkie commented 10 years ago

Ok, so after some more research I found a tiny bug causing this issue.

1) This reload would not be happening if the PMS was not responding. Those failures are NOT image failures, so a reload wouldn't be called. The slideshow would just keep moving on to the next index and keep trying..

2) These failures are the fact the requested metadata for the image to display was successful, but when the slideshow tried to show the image it failed because the expected metadata for the current image did not exist ( not the required parts). This is where the BUG took place. I have fix coming for this. Issue stems from pending requests competing with new requests.. out of order issue.

Here is the flow of the bug which will be fixed.. I am laying it out as simple as I can, so please don't look too far into this.

showing Item A
while viewing item A, buffer request sent for next image B
buffer request still waiting for response from PMS
slideshow ready to show B -- still no metadata, so new request sent
- this is where it should cancel any pending requests (fix)
slideshow is deactivated waiting for item B (health check will re-enable if too long)
response comes in for the buffer request, so this item is exptected to be item C
- this is wrong (instead of assuming, item index will be passed so it's always accurate)
- this also shouldn't happen anymore by cancel requests above
so now, then expected metadata is missing, but it was a buffer request, so it's not a important failure, however it reactivates the slideshow.
slideshow moves on to item C now, again it has to deactivate the slideshow waiting for C
slideshow gets a response for item B ( not buffered, so it tries to show it )
slideshow tries to show the current item, which is C -- but C hasn't succeeded yet.
- again this shouldn't happen any more by canceling pending request and passing the actual index

TL;DR -- found a fix.

sa2000a commented 10 years ago

Thanks for the update. For the grid you have hundreds of images fetched in advance but for the slideshow only 1 image ahead? Not sure how PMS would behave if you were 5 or 10 images ahead - it would only be an overhead for PMS at the beginning then the request frequency as for now

would that be a big thing to change?

ljunkie commented 10 years ago

The grid is magic. I don't have to deal with what it actually has saved in the cache. Very different structure. However, I think I might be able to introduce buffering an additional amount of items. I will include it in the next release, but if we have adverse results, I'll strip it so we can make sure this issue is fixed.

ljunkie commented 10 years ago

https://github.com/ljunkie/rarflix/raw/dev/RARflixDev-3.1.28.zip is ready for testing.

ljunkie commented 10 years ago

This has been tuned -- closing and opening a new issue in regards to pre-loading.

https://github.com/ljunkie/rarflix/issues/219

ljunkie / rarflix

tuning: reloading slideshow after failure #216