Project

General

Profile

Bug #1147

Muxes stuck on initial scan

Added by Joshua Welch over 7 years ago. Updated over 7 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Category:
DVB
Target version:
-
Start date:
2012-08-21
Due date:
% Done:

100%

Estimated time:
Found in version:
3.1.575g11f71
Affected Versions:

Description

Initial scan sticks on last mux to scan. Doesn't seem to happen if idle scanning is on.

Debug attached.


Files

scan.txt (140 KB) scan.txt Joshua Welch, 2012-08-21 23:54

Associated revisions

Revision fab1f902 (diff)
Added by Adam Sutton over 7 years ago

Updated the mux scanner to better handle cases where we no longer need to be tuned to a mux. Also general simplification with signal monitoring no longer directly influencing mux scanner code. Incidentally fixes #1147 and relates #892.

History

#1

Updated by Adam Sutton over 7 years ago

  • Category changed from 39 to DVB
  • Status changed from New to Accepted
  • Assignee set to Adam Sutton

Well my original thought was wrong, I had thought that the lack of idle scanning meant it was getting stuck on the last mux. This is partly wrong (or might be, I've not confirmed).

If the last mux is a bad one, and idle scanning is disabled TVH will have no reason to switch frequency and because the mux is bad it doesn't receive the data required to cause a fast switch event (which would terminate the scan).

I need to look at what the most appropriate solution for this is.

#3

Updated by Adam Sutton over 7 years ago

Ok,

it appears that it was actually unlocking the stuck mux, but it just wasn't informing the UI about the change. Previously it wasn't possible to call fe_stop() without a corresponding fe_tune() to UI update was only in the later. However this patch means thats not true and we need an update in both.

Fix applied to the branch, please re-test when you can.

#4

Updated by Adam Sutton over 7 years ago

  • Status changed from Accepted to Fixed
  • % Done changed from 0 to 100

Also available in: Atom PDF