Closed djp952 closed 5 years ago
EPG queries have been updated to deal with this, but nothing else yet.
A viable method has been determined to check the individual tuner DeviceAuth strings that doesn't incur downloading a bunch of data that will be discarded. My plan would be to make checking the DeviceAuth(s) as part of PVR startup, probably as a scheduled task, and this would allow me to either block tasks that will never work, or in the case of one/some auths being good, alter the user that there may be a problem with their subscription and/or registration.
Idea was from signcarver on the SD forums, and I think it will work out.
Note to self : the code added to allow a "no tuners" condition has also become problematic and should be solved at the same time. If there are legitimately no tuners, like the network is messed up, the old device auth codes will still be used, and just cause a bunch of 403 errors. The new method should separate out the authorization(s) from the tuner(s) so if they fail to refresh the backend won't get called at all.
Fixed for version 2.0.0. Implementation uses the 'account' API during discovery to determine if the user has DVR authorization or not. All device auth strings are validated to be non-null and now are sent into the database API calls from the PVR layer, providing the opportunity to block/log/throw as appropriate.
Making this an issue since the resolution is non-trivial and may require some fundamental changes and perhaps a database schema update.
The problem is that a user has a PRIME tuner that is not exposing a DeviceAuth code via the JSON data. It's most likely a tuner issue as they indicated the CableCard status is showing as invalid, but the PVR doesn't handle this well.
The PVR makes an assumption in a great deal of places that there will be at least one valid DeviceAuth code available. If there are none, the backend HTTP query ends up sending in "DeviceAuth=", which of course fails.
The simplest solution would be to systemically eliminate tuners without a DeviceAuth code from the device discovery altogether. If there are no tuners with any DeviceAuth codes, it would behave as if there are no tuners at all, which seems reasonable. The user will be altered to that fact at startup with recent other changes made.
As part of this, I should also add something to completely block/eliminate any backend HTTP requests if there are no tuners. Right now it will still try (and fail), which is fine for the user but unnecessarily bangs against SiliconDust's servers with no possibility of success.