Mythtv does not LOCK the HDHomeRun Prime Tuner when in use

[pyrodex@…]

When mythtv begins to access the hdhomerun it will record fine, however it does not lock the tuner. Below is a sample of a tuner from mythtv and the other tuner is being used by WMC:

Mythtv:

Virtual Channel 702 WSB_ABC Frequency 591.000 MHz Program Number 1 Authorization unspecified CCI Protection none CGMS Protection none Modulation Lock qam256 PCR Lock locked Signal Strength 74% (-15.9 dBmV) Signal Quality 82% (32.6 dB) Symbol Quality 100% Streaming Rate 11.065 Mbps Resource Lock none

WMC:

Virtual Channel 702 WSB_ABC Frequency 591.000 MHz Program Number 1 Authorization unspecified CCI Protection none CGMS Protection none Modulation Lock qam256 PCR Lock locked Signal Strength 74% (-15.8 dBmV) Signal Quality 82% (32.6 dB) Symbol Quality 100% Streaming Rate 7.759 Mbps Resource Lock 192.168.15.156

[robertm]

We don't support sharing tuners with other applications at the same time and thus the locking API is unneeded for supported use cases. If you want to submit a patch to add locking, we are happy to look at it.

[andyvt@…]

HDHR locking patch

[andyvt@…]

I would like it if you would consider applying the attached patch which enables tuner locking. I understand that sharing tuners is not a supported use case, but with the HDHR supporting multiple consumption points over DLNA and on clients that MythTV does not support this ensures that if MythTV is using a tuner another application doesn't steal it away.

Thanks

[pyrodex@…]

@andyvt

I appreciate the patch and it is a great start! I just tested it out and it seems to work in general but I think there could be some improvement here.

I started a recording with mythtv and it absolutely locked the resource to the MythTV IP address for Tuner 0 on my HDHR Prime. Then I started up the HDHomeViewer on my Windows box and it locked Tuner 1 to it's IP address without issues and Tuner 0 was still recording perfectly fine. Now here is the problem I encountered... When I tried to record another show at the same time with mythtv it seems that it tried to grab Tuner 1 since it was next in line in it's mind and saw the resource lock. The system errored out and the recording failed to try again on another tuner available. I have two HDHR Primes so I have a total of 6 tuners and I know it had 4 more free tuners during my test.

Ideally mythtv should attempt to lock a tuner, if the lock fails go onto the next free tuner in the list and attempt to lock it until it finds a viable tuner or all of them are identified as locked.

[andyvt@…]

@pyrodex I think that's a great idea. Does MythTV support tuner failover in general (i.e. would it use your 2nd PRIME if the 1st one went missing for some reason)? I copied the approach used when a streaming failure occurs, so maybe there's a better return value available.

I just started using MythTV, so please forgive any unwitting ignorance on my part :).

[pyrodex@…]

@andyvt I believe that mythtv records internally what tuners are in use and free. I thought I read somewhere that if there were no free tuners it would not record but then try later based on scheduling.

However your thought of a down HDHR if a user has more than one and trying to find an alive one during the tuner probe it would be part of the finding a free tuner resource code.

Here is how I would envision the locking/free/busy to work. In my scenario I have 6 tuners across 2 HDHR Primes for this example.

The first need would be to logically get a count of available tuners configured by the user (6 in my example). Find out how many are active in recording from MythTV's point of view (Let's say 2 in this example and find out the tuner details) Take the available free tuner and query it for a resource lock. Tuner 3 is locked by another DLNA client (bummer). Tuner 4 is locked by another DLNA client (bummer). Tuner 5 is free! Lock it and start recording. Report recording success.

Thoughts?

[gigem]

Please move your wishlist discussion to mythtv-dev or mythtv-users. MythTV expects exclusive use to all configured tuners and does not support any form of failover. This patch is only being reconsidered as an extra protection to prevent another application from taking the tuner while a recording is in progress.

[gigem]

I discussed this issue with some of the other developers on IRC. While we want to do the right thing wrt HDHR locking, this patch isn't enough. We also want to be able to dynamically allocate HDHR tuners on those devices that support them. When we have that, we'll also add support for scheduling around tuners that are temporarily locked by something else. Unfortunately, we don't have anyone to work on this at the moment. Consequently, I'm changing this ticket to an unassigned developer task. Volunteers for working on any or all of it are welcome.

[andyvt@…]

[begin quote]

I think you are misunderstanding. While the HDHR supports allocating tuners from a pool, MythTV does not support it. Applying the supplied patch will cause MythTV to lock the tuner while MythTV uses it, thereby preventing another application from interrupting MythTV's use of the tuner. It will not, however, prevent MythTV from wanting to use a specific tuner even when some other application is already using it. That's because MythTV is currently written to the tuners statically allocated to it by number and expects to have exclusive access them.

To reword that last comment from the original ticket -- We do not want a partial solution to the problem. We will only accept patches that solve the entire problem. That means changing MythTV to configure an hdhomerun_device_selector_t object and to use hdhomerun_device_selector_choose_and_lock() to allocate tuners dynamically. [end quote]

You are correct, I do not understand how MythTV allocates tuners. If the current implementation does not allow for dynamic tuner allocation, then adding locking won't impact that limitation. It only enforces MythTV's use of a tuner while it is using it.

I will have a look at how MythTV allocates tuners to see how easy it is to change, but I must say that taking an-all-or-nothing, even when the middle ground leaves MythTV in a better, more supportable, state strikes me as a bit odd.

When evaluating MythTV as a potential replacement for my current solution I lost recordings due to this issue, ran down the root cause, downloaded the source, and implemented an easy change that stops that from happening. As far as I can tell, even though "incomplete" there is no negative impact to adding it - even if only until someone (maybe me) can add support for dynamic tuner allocation. Obviously it's your app, can do whatever you want, but it's unwelcoming and strange.

[Gary Buhrmaster <gary.buhrmaster@…>]

The "easy" solution to sharing is "don't", and if that requires network isolation (usually sub-netting, although PACLs can sometimes be used), that is a trivial exercise to achieve the desired result with none of the identified downsides. While I would like sharing, I have chosen network isolation because I have not found the resources to "do it right". It should be noted that most apps do not share well. SageTV does not share well. WMC sort of shares, but you get interesting results as the recordings fail, and then it retries (which may or may not work). AFAIK only the apps provided by SiliconDust? (surprise surprise) share well, and then (of course) only with their other apps that are sharing well.

Not that I am committing any resources, but I wonder if the locking of all configured tuners at backend startup (and then running a background thread to keep them locked) would be an adequate initial solution to this problem. That would eliminate the issues that MythTV encounters, and insure (reasonably) proper scheduling decisions since the number of available tuners would be (mostly) accurate.

[Gary Buhrmaster <gary.buhrmaster@…>]

Replying to andyvt@…: ....

You are correct, I do not understand how MythTV allocates tuners. If the current implementation does not allow for dynamic tuner allocation, then adding locking won't impact that limitation. It only enforces MythTV's use of a tuner while it is using it.

I think you misunderstand. You will lose recordings if another app already has the tuner in use (with a lock). So in some scenarios you might win, but in others you have not improved your reliability (and that does not even include the scheduling challenges when the number of tuners changes at the time of the attempted recording).

[Karl Egly]

Replying to Gary Buhrmaster <gary.buhrmaster@…>:

The "easy" solution to sharing is "don't"

I like that. Locking HDHR tuners (​40% of the registered tuners according to Smolt) at backend startup (with an option of lazy locking) would bring that recorder on par with DVB tuners (47% of the registered tuners).

In the end MythTV is designed for dedicated hardware. But that hardware may be a subset of the available tuners of your HDHR device. E.g. two dedicated tuners and one shared tuner (with the least priority for recordings)

[andyvt@…]

Replying to Gary Buhrmaster <gary.buhrmaster@…>:

Replying to andyvt@…: ....

You are correct, I do not understand how MythTV allocates tuners. If the current implementation does not allow for dynamic tuner allocation, then adding locking won't impact that limitation. It only enforces MythTV's use of a tuner while it is using it.

I think you misunderstand. You will lose recordings if another app already has the tuner in use (with a lock). So in some scenarios you might win, but in others you have not improved your reliability (and that does not even include the scheduling challenges when the number of tuners changes at the time of the attempted recording).

Right now:

• Other app has tuner lock, MythTV loses. Recording failure
• MythTV is using a tuner, other app takes tuner. Recording failure (even if available tuners are not in use).

With patch:

• Other app has tuner lock, MythTV loses. Recording failure.
• MythTV is using a tuner, other app cannot take tuner. Recording succeeds.

I understand that it will not fix all the problems, but it reduces the incidence of failure.

[gigem]

andyvt, I understand ouor all-or-nothing attitude probably comes across as too harsh. It's purely to encourage those with the time, motivation and skill to take the current patch and extend it into a more complete solution.

[Stuart Auchterlonie]

I believe we should add this patch. It clearly fixes an issue (that of a recording being interrupted when it was successfully started) and does not change the failure scenarios if the device was already in use.

Stuart

[us@…]

I have a rhetorical question.

What does MythTV backend do if it has a HDHomeRun tuner configured for recordings and the tuner is powered off? If it bypasses that tuner, couldn't the locking work in a similar way?

[gigem]

In that situation, MythTV will continue to try to use the tuner and fail the recordings when they are supposed to start. The reason is that MythTV currently has no concept of an individual tuner being off-line. There is support for all tuners on a slave backend being off-line, but that is a different situation because the master backend knows when slaves connect and disconnect. What we need is for MythTV to poll networked tuners periodically to know when they are unavailable. As always,patches are welcome.

FYI, the consensus among the developers has changed regarding the locking patch. We now want to include it, but there is a problem. If the MythTV backend crashes while streaming, the lock can sometimes still be in place when the backend restarts which can lead to more failures. We're waiting on word from Silicon Dust on how to proceed. Eventually, we want to change the HDHR support to use HTTP streaming instead of RTP. In that scenario, the lock is freed by the HDHR as soon as the TCP connection is broken.

[Andrew Cornford <andrewcornford@…>]

Is there any news on this from Silicon Dust? I have just bought one of these tuners and I would like to be able to watch TV on my phone using DNLA without worrying that I might stop a recording on MythTV.

I'm not great at coding but if I can help out with testing or anything else I'd be more than happy to do so.

[Karl Egly]

Replying to dekarl:

Replying to Gary Buhrmaster <gary.buhrmaster@…>:

The "easy" solution to sharing is "don't"

I like that. Locking HDHR tuners (​40% of the registered tuners according to Smolt) at backend startup (with an option of lazy locking) would bring that recorder on par with DVB tuners (47% of the registered tuners).

In the end MythTV is designed for dedicated hardware. But that hardware may be a subset of the available tuners of your HDHR device. E.g. two dedicated tuners and one shared tuner (with the least priority for recordings)

I just ordered one of their EXPAND tuners. Lets see if that actually works as imagined.

[Karl Egly]

I'm now running with that patch applied and was reminded that our EIT scanner also locks the channel. So adding the option to disable the active EIT scanner for a HDHR tuner would be nice. Otherwise all tuners will be locked all of the time. It already works if one sets dvb_eistcan=0 manually.

[Andrew <Andrew Van Til>]

In f4693af7597c9c724a93d198774e5df16b9e94d5/mythtv:

Add support for HDHR tuner locking during recording.

This implements the protection of successsfully started recordings
against other programs trying to hijack the tuner. Not to be confused
with support for tuner sharing. It does not implement support for
finding the first unused tuner.

Patch by andyvt@

Fixes #10043

[Stuart Auchterlonie]

This doesn't appear to have been merged to fixes/0.28. Should it be merged??

[Karl Egly]

Bump to 29.0 for now, as it is a contested change, was close to the release and affects many users.