Project

General

Profile

Bug #1147

Muxes stuck on initial scan

Added by Joshua Welch about 12 years ago. Updated about 12 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Adam Sutton
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

History

#1

Updated by Adam Sutton about 12 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 about 12 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 about 12 years ago

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

Applied in changeset commit:fab1f902bbb46d3cc612996e382064527dc670c9.

Also available in: Atom PDF