2021-06-14, 06:42
what is your timezone set to in OSMC?
I'm going to PM you so we don't fill up this thread with testing back and forth
UPDATE:
OK, all fixed in latest Slyguy Common (v0.32.8) and Disney+ (v0.6.8)
The issue was Black Widow had an availability date of "2050-01-01T07:00:00Z"
I assume this is a "placeholder" date until the actual date is added in
I also use an older API due to it providing more data so maybe that isn't helping either.
Now, I use arrow to process dates which handles it fine until I call .to('local') to convert it to local timezone.
Arrow goes away and calls some other functions which can't handle the large timestamp the above generates.
On 32bit, largest timestamp is 2038-01-01 and largest on 64bit is 3000-01-01
Arrow has a workaround to allow larger timestamps but the .to() method uses tz in dateutil that doesn't have such a workaround.
I've opened an issue on Arrow below to make them aware:
https://github.com/arrow-py/arrow/issues/991
To fix it, I have patched the tz in dateutil in sly common to use Arrows normalize_timestamp function to fix the timestamp overflow
https://github.com/matthuisman/slyguy.ad...1622731c75
Now, obviously 2050 is not the actual available date - so in latest Disney+ - for any available date more than a year in the future, it will just say "Coming Soon"
https://github.com/matthuisman/slyguy.ad...f8abf60ad1
I'm going to PM you so we don't fill up this thread with testing back and forth
UPDATE:
OK, all fixed in latest Slyguy Common (v0.32.8) and Disney+ (v0.6.8)
The issue was Black Widow had an availability date of "2050-01-01T07:00:00Z"
I assume this is a "placeholder" date until the actual date is added in
I also use an older API due to it providing more data so maybe that isn't helping either.
Now, I use arrow to process dates which handles it fine until I call .to('local') to convert it to local timezone.
Arrow goes away and calls some other functions which can't handle the large timestamp the above generates.
On 32bit, largest timestamp is 2038-01-01 and largest on 64bit is 3000-01-01
Arrow has a workaround to allow larger timestamps but the .to() method uses tz in dateutil that doesn't have such a workaround.
I've opened an issue on Arrow below to make them aware:
https://github.com/arrow-py/arrow/issues/991
To fix it, I have patched the tz in dateutil in sly common to use Arrows normalize_timestamp function to fix the timestamp overflow
https://github.com/matthuisman/slyguy.ad...1622731c75
Now, obviously 2050 is not the actual available date - so in latest Disney+ - for any available date more than a year in the future, it will just say "Coming Soon"
https://github.com/matthuisman/slyguy.ad...f8abf60ad1