Opened 8 years ago

Closed 5 years ago

#13058 closed Bug Report - General (fixed)

Fully tuned scan of a satellite delivery system fails to tune new multiplexes

Reported by: Roger James <roger@…> Owned by: Klaas de Waal
Priority: minor Milestone: 31.0
Component: MythTV - DVB Version: Master Head
Severity: medium Keywords: DVB
Cc: Ticket locked: no

Description

A fully tuned scan of a satellite delivery system fails to tune new multiplexes.The code in channelscan_sm.cpp incorreclty divides the frequency returned from SatelliteDeliverySystemDescriptor::FrequencyHz?() function by 1000. The frequency retruned is already in KHz. I have fixed this by removing the division and renaming the function FrequencyKHz().

Pull request #138 has the patch.

Roger

Change History (6)

comment:1 Changed 8 years ago by Stuart Auchterlonie

Owner: set to Stuart Auchterlonie
Status: new → accepted

comment:2 Changed 7 years ago by Stuart Auchterlonie

Milestone: 29.0 → 29.1

comment:3 Changed 7 years ago by Stuart Auchterlonie

Milestone: 29.1 → 0.28.2

Moving remaining open tickets to 0.28.2 milestone

comment:4 Changed 7 years ago by Stuart Auchterlonie

Milestone: 0.28.2 → 29.2

Moving remaining open tickets to 29.2 milestone

comment:5 Changed 5 years ago by Klaas de Waal

Milestone: 29.2 → 31.0
Owner: changed from Stuart Auchterlonie to Klaas de Waal
Status: accepted → assigned

The patch is found in ​https://github.com/MythTV/mythtv/pull/138/commits/4cdae5ba9fcad79bc3546fec6b5f746543912468. The problem described is still present in today's master.

comment:6 Changed 5 years ago by Roger James <roger@…>

Resolution: → fixed
Status: assigned → closed

In 5575f4f6a7/mythtv:

Hz/kHz confusion in SatelliteDeliverySystemDescriptor?

In SatelliteDeliverySystemDescriptor? the function FrequencyHz?
did return the frequency in kHz. This is, although misleading,
not a real bug because almost everwhere the value was correctly
interpreted as a frequency in kHz, as is standard for all
frequencies in the context of satellites.
Only in the channel scanner, where the NIT table is parsed
for additional transports, the result of FrequencyHz? was
divided by 1000 and this resulted in a value in MHz.
Contrary to what the title of ticket #13058 suggests,
this did not prevent finding and scanning new multiplexes.
The code uses the frequency value to search for an existing
multiplex and if it cannot find it then a new multiplex is created.

Fixes #13058

Signed-off-by: Klaas de Waal <kdewaal@…>

Note: See TracTickets for help on using tickets.