HDHomeRun recorder repeatedly setting filter tracking ticket

[Gary Buhrmaster <gary.buhrmaster@…>]

After the reports on list, irc, and the SD forums indicated that there was an issue with the MythTV HDHomeRun recorder repeatedly issuing set filter, I have performed a git bisect of MythTV, and the result is that the first commit that is causing the problem appears to be 9b22460f53bf6313516f33987e4260897c6076a3 which is "Merge of various recorder changes from mythtv-rec2". This seems to generate new filter updates hundreds (or more) times per second. The second commit 0542a100237dd26bcbc60212c443f4619586f15b "Refs #10414. Lower HDHomeRun recorder CPU usage a tiny bit more." sets a timer to only update the filters about 10 times per second (the currently observed rate). For testing purposes, I have created a patch against fixes/0.26 which updates the filter on the hdhomerun only when the code indicates that the filter list has been changed (attached). It should not be considered complete, but simply as a proof of concept. In particular, I have not looked at EIT filter changes, nor other recorders.

Kenni Lund suggested that I submit this ticket.

[Gary Buhrmaster <gary.buhrmaster@…>]

Proof of concept filter patch

[Silicondust]

Related... the filter should not be set at all if QuickTune? is used.

QuickTune? tells the HDHomeRun to find the specified program and auto-set the PID filter.

Worked correctly in 0.24. In later releases MythTV sets the filter thus clearing the quicktune mode.

Nick

[stuartm]

Gary, I don't suppose you have an updated patch which might be considered complete?

[Gary Buhrmaster <gary.buhrmaster@…>]

Well, the patch, as submitted, worked for me, with no negative impacts. But I really (really (really)) wanted someone with expertice in the dvb code to look it over (perhaps danielk at the time, since he was the author of much of the recent code?) since my knowledge of the intricacies of all the various classes was (and is) limited, and I could have easily missed a code path that needed to be addressed. I will admit that usually when I try to get my head around the recorder code, I up being lost in a maze of classes all alike (but different). I no longer use a HDHR in non-OCUR mode (i.e. my clear QAM days have long since been encrypted out of existence, and OTA is not viable at the moment), so the patch no longer matters to me. It should be noted that SiliconDust? has updated their firmware so that the impact of continuously (10 times per second) updating the filters is no longer operational impacting for that device (which was the only device directly fixed by this patch). Perhaps the ticket should be closed as wontfix (or fixed upstream?) for ticket cleanliness.

[Klaas de Waal]

The PID filter is set about 10 times per second. In my understanding it only needs to be set when the list of PIDs to listen to is changed.

[Gary Buhrmaster]

Replying to Klaas de Waal:

The PID filter is set about 10 times per second. In my understanding it only needs to be set when the list of PIDs to listen to is changed.

Correct. And that was what the patch attempted to do (when submitted seven or so years ago), although not at all elegantly.

[Stuart Auchterlonie]

Closing out old tickets. HDhomerun support has changed substantially since this was raised.

[Klaas de Waal]

Patch updated for today's master. Under test.

[Klaas de Waal]

Gary's patch updated for today's master.

[Klaas de Waal]

Fixed in commit f8a45f9700777aaedb0ca09d5bfe8e63d0c29283.