Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to address the tuners as a pools instead of strictly individually. #18

Closed
enternoescape opened this issue Dec 16, 2015 · 2 comments

Comments

Projects
None yet
1 participant
@enternoescape
Copy link
Owner

commented Dec 16, 2015

This feature will allow you to address the tuners as a pool instead of directly. This would make the tuner provided to SageTV a virtual tuner since it doesn't have a direct assignment. This allows for specifically HDHomeRun users to access a group of tuners in order of preference and availability. In order to keep things familiar, we will use the same merit system that SageTV uses to determine the order of selection. One criteria for skipping a tuner with a higher merit than another tuner would be if the higher merit tuner is currently locked by another computer/device. The locks would only be overridden if there is no other option and the override would be performed starting at the highest merit first.

The reason for pools instead of just grouping all of the available tuners into one big pool is because you could have unexpected issues while tuning. For example, let's say we have 2 tuners. One DCT and one ClearQAM. The DCT has all channels available and the ClearQAM only has a subset available. SageTV tunes a DCT channel that happens to also be a ClearQAM channel and OpenDCT selected the ClearQAM tuner since the DCT tuner is currently in use by another program. No problem. It tunes it and it works. SageTV then tunes a ClearQAM channel and OpenDCT selects the DCT since it's all we have left; also no problem. SageTV then tunes a DCT channel while the DCT is already in use on a ClearQAM channel. The ClearQAM tuner can't tune the channel and it fails. The only way to work around this would be to have OpenDCT dynamically swap the tuners around, but that may be an unrealistic approach since we would need to make sure everything lines up perfectly or people will not be happy with their chopped up recordings. Also this would require more time than many people might prefer just to tune into a channel if everything is all jumbled up.

Care needs to be taken to ensure that this doesn't impact tuning performance in any significant way. I think our goal should be to have a result in less than 100ms. If we can keep everything under that time frame even if unexpected things happen like a tuner disappears from the network, we will maintain the nice responsiveness that we already have.

This feature would also provide the ground work for us to do other cool things like consolidation between multiple SageTV servers. For example you could have multiple SageTV servers using the same tuners. If a request hits the pool for a channel that's already tuned, the stream would just be split between the two servers instead of using up another tuner. The NOOP response could be used to let SageTV know when tuners are being used by another server. In the event that we can consolidate a channel, the NOOP response would come back for one of the tuners. I could only see this ending badly if both servers start recordings on completely different channels all at the same time.

@enternoescape enternoescape self-assigned this Dec 16, 2015

@enternoescape enternoescape added this to the 0.4 milestone Dec 16, 2015

@enternoescape

This comment has been minimized.

Copy link
Owner Author

commented Dec 17, 2015

This was not as hard to implement as I thought. I will need to do additional testing, but so far the results of only 2 days of work are looking very good. The only thing I would like to improve is responsiveness if a device drops off the network. This feature in it's entirety can be disabled and is disabled by default.

@enternoescape

This comment has been minimized.

Copy link
Owner Author

commented Dec 19, 2015

The ability for pooling in now available and it is fully compatible with all current configurations. I thought we might want to multi-thread the queries, but unless you have a capture device down, it doesn't look like it will make any noticeable improvement in performance and even has the potential to slow things down since we need to start each thread. The capture device has been made responsible for telling the pool if it is available in two ways. The first one is the internal lock which is set by SageTVRequestHandler and if requested, SageTVPoolManager. The second one is the external lock. The external lock will also report the device as locked if it is inaccessible. If the external lock is unsuccessfully cleared, then it moves on to the next capture device. If all options fail, it tries to tune the highest merit, not internally locked device regardless getting a successful external unlock. There is timing built in when using DEBUG for logging that has shown me the normal impact is less than 20ms 99.9% of the time and often closer to 4ms. The only annoying thing this will introduce is that within SageTV you will never be completely sure what tuner recorded your show. I think we should leverage something like Sagex to change the recording device to the one that actually did the recording on it's own thread when SageTV sends STOP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.