-
Notifications
You must be signed in to change notification settings - Fork 345
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
Comments
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
5 tasks
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
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
The text was updated successfully, but these errors were encountered: