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

UpdateFilters called in wrong tune mode for HDHomerun Prime #905

Closed
SteveErl opened this issue Jun 1, 2024 · 0 comments · Fixed by #906
Closed

UpdateFilters called in wrong tune mode for HDHomerun Prime #905

SteveErl opened this issue Jun 1, 2024 · 0 comments · Fixed by #906

Comments

@SteveErl
Copy link
Contributor

SteveErl commented Jun 1, 2024

  • Platform: All

  • MythTV version: v35-Pre

  • Package version:

  • Component: mythbackend

What steps will reproduce the bug?

Using an HDHomerun Prime with a cablecard installed, every time a channel is tuned in, an Error message is written into the mythbackend.log.

How often does it reproduce? Is there a required condition?

100% of the time. You need a tuner with a cablecard.

What is the expected behaviour?

Successful tuning in of a channel should not cause generation of an error message. Also, such an error message should be less vague. What tune mode was considered wrong?

What do you see instead?

Here's an example:

mythbackend: mythbackend[728481]: E HDHRStreamHandler hdhrstreamhandler.cpp:242 (UpdateFilters) HDHRSH[3](13122384): UpdateFilters called in wrong tune mode

Additional information

SteveErl added a commit to SteveErl/mythtv that referenced this issue Jun 1, 2024
The first step is to improve the error messages. In two places
the "UpdateFilters called in wrong tune mode" message has been
updated to specify the value of the wrong tune mode.

After this update, an example of the error message is:

 mythbackend: mythbackend[779282]: E HDHRStreamHandleri
   hdhrstreamhandler.cpp:242 (UpdateFilters) HDHRSH[4](13249773):i
   UpdateFilters called in wrong tune mode, 4

From this, we know that the tune mode was hdhrTuneModeVChannel.
We know that UpdateFilters was called, but in hdhrstreamhandler.cpp,
the only call to it is avoided for Vchan tuning.

108 void HDHRStreamHandler::run(void)
...
140             UpdateFiltersFromStreamData();
141             if (m_tuneMode != hdhrTuneModeVChannel)
142                 UpdateFilters();

Code examination revealed that the offending invocation of
UpdateFilters() is in RemoveAllPIDFilters().

This routine is called unconditionally in

108 void HDHRStreamHandler::run(void)
...
183     LOG(VB_RECORD, LOG_INFO, LOC + "RunTS(): " + "shutdown");
184
185     RemoveAllPIDFilters();

The solution is to condition the call to RemoveAllPIDFilters()
in the same way the call to UpdateFilters() was previously
conditioned. If we're using Virtual Channel Tuning, then don't
bother removing filters which were never created in the first
place.

Resolves MythTV#905
kmdewaal pushed a commit that referenced this issue Jun 1, 2024
The first step is to improve the error messages. In two places
the "UpdateFilters called in wrong tune mode" message has been
updated to specify the value of the wrong tune mode.

After this update, an example of the error message is:

 mythbackend: mythbackend[779282]: E HDHRStreamHandleri
   hdhrstreamhandler.cpp:242 (UpdateFilters) HDHRSH[4](13249773):i
   UpdateFilters called in wrong tune mode, 4

From this, we know that the tune mode was hdhrTuneModeVChannel.
We know that UpdateFilters was called, but in hdhrstreamhandler.cpp,
the only call to it is avoided for Vchan tuning.

108 void HDHRStreamHandler::run(void)
...
140             UpdateFiltersFromStreamData();
141             if (m_tuneMode != hdhrTuneModeVChannel)
142                 UpdateFilters();

Code examination revealed that the offending invocation of
UpdateFilters() is in RemoveAllPIDFilters().

This routine is called unconditionally in

108 void HDHRStreamHandler::run(void)
...
183     LOG(VB_RECORD, LOG_INFO, LOC + "RunTS(): " + "shutdown");
184
185     RemoveAllPIDFilters();

The solution is to condition the call to RemoveAllPIDFilters()
in the same way the call to UpdateFilters() was previously
conditioned. If we're using Virtual Channel Tuning, then don't
bother removing filters which were never created in the first
place.

Resolves #905
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant