Conflict between 1 live TV and 1 scheduled recording with multi-tuner setup

[andrew@…]

On a system with a quad-TV tuner card where each tuner has "max recordings" set to 4, the MythTV backend sends 4 ASK_RECORDING messages when a scheduled recording begins (one for each "encoder" belonging to the tuner - e.g. 1,2,3,4 for the first tuner).

(IMPORTANT NOTE: I had the live TV and recording orders all set to 1. I've since changed this to be 1-2-3-4 and 4-3-2-1 as per a workaround I found online. The information below assumes all tuners are set to have an order of 1 for both live TV and recording.)

I begin watching live TV and the web frontend shows me that this is assigned to encoder 1.

If I begin watching live TV on another system, the web frontend shows me that this is assigned to encoder 5 (next will be 9, then 13). This itself seems quite strange - shouldn't the same tuner be used in cases where a channel is multiplexed on the same frequency as another?

When a recording starts (either manually started or via a scheduled recording), 4 ASK_RECORDING messages are sent. In this example, the messages relate to encoders 1 thru 4. My understanding is that these are to allow a front-end to decide whether to cancel a recording or stop live TV. I am watching live TV on encoder 1 and this immediately stops so that recording can begin.

It seems really strange that the backend chooses to send ASK_RECORDING for encoders 1,2,3,4 when encoder 1 is already busy with live TV. I'd expect it to send it for just 2,3,4 or for 5,6,7,8 (if the second tuner was completely idle).

Surely it would make sense that:

1. If the channel to be recorded is multiplexed on the same frequency as the live TV channel then it should send the other encoders apart from the one that is being used?

2. In the event that the channel is on a different frequency and the first tuner (in the "order") is busy with live TV, the other tuners should be considered.

At the moment I have only been using this with the Kodi MythTV add-on, and initially I thought it was a bug with that, but it looks like it may be in the MythTV backend after all. When I get some time I will try this with the MythTV frontend as well to see if it behaves the same (a brief look at the source code suggests that it might).

Sorry if I have missed out any needed detail or filed this incorrectly, please let me know if you need any more information.

[gigem]

Andrew, I'm closing this ticket because I believe the backend currently works as intended. Now, that in now way means that it can't and won't be improved. Rather, it means there is nobody currently available to work on it that part of MythTV and we don't use tickets to track feature requests and wish lists unless they are accompanied by patches.

That being said, if you'd like to discuss the live TV issues further, I'd be happy to do so on the mythtv-dev mailing list. I have ideas on what I'd like to do, but it's highly unlikely that I'll get to them any time soon. If you have the time and ability to do some of the work, I can try to point you in the right direction.

[andrew@…]

Thanks for your comments. It initially looked like a bug due to the backend offering an encoder for recording that is busy with live TV, but I see your point: It all still works, even if it might behave in the way I'd expect.

I'd consider contributing to the development. Having looked at the code in the backend that sends out the ASK_RECORDING messages I already have a rough idea how it works.

I have a workaround at least but I'll give it some consideration and may come to the mythtv-dev mailing list in future to discuss this.

Thanks!