Opened 13 years ago

Closed 10 years ago

#1866 closed defect (fixed)

DVB Scanning - Remaining Issues

Reported by: Stuart Auchterlonie Owned by: danielk
Priority: minor Milestone: 0.22
Component: channelscan Version: head
Severity: medium Keywords: dvb scanning
Cc: Ticket locked: no

Description

  • When the NIT is received before the SDT, the transport

is processed as though the SDT had been received, causing no channels to be inserted.

  • Tuned Scan does not use the information found in the

NIT to find other transports to scan, as it did in previous releases.

  • Lyngsat NITs do not properly describe the transmission

parameters, in particular FEC, for some transports. They are described as 7/8 when they are actually 5/6. Need to read back this information from the card.

Attachments (1)

dvbsnoop-tvhome-dvbc-nl.zip (5.5 KB) - added by petermartens@… 13 years ago.
Dvbsnoop output for dvb-c, TVHome Netherlands

Download all attachments as: .zip

Change History (18)

comment:1 Changed 13 years ago by anonymous

Trying ticket nofications here.

comment:2 Changed 13 years ago by Stuart Auchterlonie

Status: newassigned

UK Multiplexes no longer transmit other_frequency flags and frequency descriptors to work around bugs in various STB's.

Need to pull the current tuning information off the card and believe that in preference to the NIT (this is the same problem as Lyngsat's FEC issues)

comment:3 Changed 13 years ago by Janne <janne-mythtv@…>

Component: mythtvdvb

comment:4 Changed 13 years ago by petermartens@…

As asked by Stuart, the output of dvbsnoop when tuning to a transport for dvb-c (TVHome, Netherlands). Scan is not inserting the right frequencies somehow.

When looking through the file, I saw that the frequencies mentioned are not valid transports over here. The network id also doesn't seem right (It is 1111, if I recall correctly). But I am a total noob in these things.

Please contact me for further information.

Changed 13 years ago by petermartens@…

Attachment: dvbsnoop-tvhome-dvbc-nl.zip added

Dvbsnoop output for dvb-c, TVHome Netherlands

comment:5 Changed 13 years ago by Stuart Auchterlonie

(In [10736]) Refs #1866. Descriptor toString() updates

Implements toString() function for the TerrestrialDeliverySystemDescriptor?, SatelliteDeliverySystemDescriptor? and CableDeliverySystemDescriptor?

Previously these were only stub functions.

Makes the FrequencyListDescriptor? return frequencies in Hz, not Hz/10.

comment:6 Changed 13 years ago by Stuart Auchterlonie

(In [10755]) Closes #2033, Refs #1866. Fixes siscan to correctly wait for both NIT & SDT. Correctly set rotor target information.

comment:7 Changed 13 years ago by Stuart Auchterlonie

(In [10847]) Refs #1866. Adds FindBestMplexFreq?.

This add some fuzzy matching to the frequency for dvb-t systems. Previously we would ask the card to tune on a frequency from the frequency list. This would often not be the actually frequency that the mplex is on, but one of the offset frequencies, and the card just managed to pull itself together and get lock.

The NIT will have populated that DB with the mplexes and their frequencies. So we can check the currently tuned frequency against what the NIT provided. If this frequency equals either the centre frequency or one of the offset frequencies then we use the value we already have. If we don't already have a frequency or the frequency isn't one of the offsets (as would happen on a repeater mux) then just use the frequency we tuned to.

comment:8 Changed 13 years ago by Stuart Auchterlonie

Resolution: fixed
Status: assignedclosed

The behaviour of tuned scan as it now exists is to tune to the given transport and just scan that. ie. It's the same as transport scan just with a user defined tranport.

Previously (mythtv <= 0.19) the information received in the NIT would be used to add other transports to the list to be scanned.

The current behaviour is more logical from a users point of view, since they asked it to scan the given transport, and are not expecting it to go wandering off scanning other transports.

The old behaviour can be acheived by doing the tuned scan, and then existing transport scan, as the tuned scan will populate dtv_multiplex from the NIT found on the first transport.

Alternatively, full scan is available to find all the transports being broadcast, which will work even if the transports do not provide any information about other transports, as happens in certain countries.

comment:9 Changed 13 years ago by Stuart Auchterlonie

Milestone: 0.200.21
Resolution: fixed
Status: closedreopened

Tuned scan still needs to be fixed, but it's not a trivial change. Bumping it to 0.21

comment:10 Changed 13 years ago by sbrown@…

The .20 code is not very tolerant of misconfigured DVB-S encoders. Hispasat illustrates this.

  • 11934's NIT lists 2 transport streams (1 & 2), while the SDT references TSID 0. This results in a timeout. Also, the NIT transport streams have no descriptors, so handle_transport_desc doesn't get called and the transports are never loaded.
  • 11884 loads a transport and channels, but the transportid & networkid are both 1.
  • 12168, when scanned, overwrites transport 11884 because its transportid & networkid are also both 1.
  • The channel numbers on 11884 & 12168 are not unique, so selection by number won't work.

I have dvbsnoop's of all these if they are useful. Hope these comments are appropriate for this ticket.

comment:11 Changed 13 years ago by danielk

(In [11702]) Refs #1866. Refs #2600. Replaces DVBTuning with DTVMultiplex which does not depend on DVB headers and uses the same string parsing routines as the dvb-utils channels.conf reader.

This DTVMultiplex is then used for DTVChannel::Tune() so that the different DTV channels classes no longer require custom tuning code in the channel scanner. This also gets rid of the Linux DVB header dependency in frequencytables.{h,cpp} which simplifies that code as well.

This has been tested with DVB ATSC 8-VSB/QAM-256, DVB-T, DVB-C, ivtv (which uses a DTV capable tuning class), and the HDHomeRun 8-VSB/QAM-256.

comment:12 Changed 12 years ago by rudy@…

Daniel,

Will you also take into account the following situation?

  • DVB-C
  • each TS contains several NIT-Others as well as invalid NIT-Actual (NIT-Actual present but effectively not used
  • Each NIT-Other describes the valid setup for a particular geographical area (and is identified by a different network-id)
  • the original network-id is the same on all TS

This is the network setup of @home, casema and Multikabel in NL. I have no access to Telenet (Belgium) but have reason to believe they do the same.

comment:13 in reply to:  12 Changed 12 years ago by anonymous

Replying to rudy@grumpydevil.homelinux.org:

Daniel,

Will you also take into account the following situation?

  • DVB-C
  • each TS contains several NIT-Others as well as invalid NIT-Actual (NIT-Actual present but effectively not used
  • Each NIT-Other describes the valid setup for a particular geographical area (and is identified by a different network-id)
  • the original network-id is the same on all TS

This is the network setup of @home, casema and Multikabel in NL. I have no access to Telenet (Belgium) but have reason to believe they do the same.

I've created ticket #3640 which would be this problem I think. I'm on Virgin Media cable in the UK and InsertMultiplex? code is very much doing the wrong thing.

comment:14 Changed 12 years ago by Stuart Auchterlonie

Component: dvbchannelscan

comment:15 Changed 12 years ago by Stuart Auchterlonie

Milestone: 0.210.22

comment:16 Changed 11 years ago by Dibblah

Owner: changed from Stuart Auchterlonie to danielk
Status: newassigned

comment:17 Changed 10 years ago by Janne Grunau

Resolution: fixed
Status: assignedclosed

first point is fixed by the channel scanner merge, second in [21365], unsure if the third point is fixed, but we have code to read the parameters back from the card. open a new ticket if it's not fixed.

Note: See TracTickets for help on using tickets.