[x] My code follows the code style of this project (PEP8, long lines allowed if make sense)
[x] I made sure there wasn't another Pull Request opened for the same update/change
[x] I have successfully tested my changes locally
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Adding a new region/hbo go version
Description:
This happens rarely and when it does its temporary within few hours to a few days the item will return again correct data under the parent node from the API, but until it does this will load the first episode listed and try to pull season data from that listing as an alternative way to retrieve the seasons.
If that fails as well will simply list episodes that are returned (better something then nothing).
I was able to test this on one of the rare occasions it occurred and it worked.
The next day the item was returning correct data again so this is an elusive event.
But there is one log from a different user confirming the existence of the event.
The next day the problem disappeared by itself because the API started returning correct data under the parent node again.
This implementation mitigates the event, the user won't notice anything.
I was also able to test this by creating the conditions artificially, corrupting the parent node on purpose in the cache.
Please check that your pull request pass this checks:
Types of changes
Description:
This happens rarely and when it does its temporary within few hours to a few days the item will return again correct data under the parent node from the API, but until it does this will load the first episode listed and try to pull season data from that listing as an alternative way to retrieve the seasons. If that fails as well will simply list episodes that are returned (better something then nothing). I was able to test this on one of the rare occasions it occurred and it worked. The next day the item was returning correct data again so this is an elusive event. But there is one log from a different user confirming the existence of the event. The next day the problem disappeared by itself because the API started returning correct data under the parent node again. This implementation mitigates the event, the user won't notice anything.
I was also able to test this by creating the conditions artificially, corrupting the parent node on purpose in the cache.