Jump to content

Scan not finding channel names on one tranponder


fe31nz

Recommended Posts

I have just upgraded to DVBViewer Pro 6.0.0.1.  I am using it with a minisatip SAT>IP server and a TBS-6909 DVB-S2 card to view channels from my Sky TV New Zealand satellite service.  Minisatip is decrypting the channels using [ removed, violating forum rule §13] and my Sky card.  Since the upgrade, every time I scan the Sky TV transponders, the 12519 MHz transponder channels do not have their channels names shown, just names like "Service 1002".  The names were appearing when scanning using the older version I had installed previously (5.6.3).  And when I do a scan using a script on my Ubuntu box where minisatip runs (using dvbtune and scan-s2), the names for the channels are shown:

 

[[Tuning to 12519000 Hz]]
SM Premiere;SkyNZ:1769:HC34:S0.0W:22500:1001+8181:1101=eng:0:0:1002:169:3:0
Preview;SkyNZ:1769:HC34:S0.0W:22500:1006+8186:1106=eng:0:0:1050:169:3:0
Preview;SkyNZ:1769:HC34:S0.0W:22500:1006+8186:1106=eng:0:0:319:169:3:0
RNZ National;Radio New Zealand National:1769:HC34:S0.0W:22500:0:1151=eng:0:0:1101:169:3:0
RNZ Concert;Radio New Zealand Concert:1769:HC34:S0.0W:22500:0:1152=eng:0:0:1102:169:3:0
TS3 IEPG Data Service;SkyNZ:1769:HC34:S0.0W:22500:0:1160:0:0:9003:169:3:0
Prime;SkyNZ:1769:HC34:S0.0W:22500:1013+8183:1113=eng:1913:0:1530:169:3:0
Bravo PLUS1;SkyNZ:1769:HC34:S0.0W:22500:1014+8184:1114=eng:0:0:1510:169:3:0
The Edge TV;SkyNZ:1769:HC34:S0.0W:22500:1015+8185:1115=eng:0:0:1511:169:3:0
Calvary;Calvary Chapel Radio:1769:HC34:S0.0W:22500:0:1154=eng:0:0:1107:169:3:0
Tahu FM;Tahu FM - Music From The South:1769:HC34:S0.0W:22500:0:1159=eng:0:0:1105:169:3:0
EPG Background Audio;SkyNZ:1769:HC34:S0.0W:22500:0:1160=eng:0:0:330:169:3:0
Classic R'n'B;A blend of Classis R n B and Soul:1769:HC34:S0.0W:22500:0:1157=eng:0:0:1133:169:3:0
Ad Tracks;Ad Track:1769:HC34:S0.0W:22500:0:1158=eng:0:0:1197:169:3:0
Classical;Classical - Elegant Pieces:1769:HC34:S0.0W:22500:0:1155=eng:0:0:1130:169:3:0
Kids;Kids - Music and Tunes:1769:HC34:S0.0W:22500:0:1156=eng:0:0:1131:169:3:0
Preview;SkyNZ:1769:HC34:S0.0W:22500:1006+8186:1106=eng:0:0:1000:169:3:0
Prime PLUS 1;SkyNZ:1769:HC34:S0.0W:22500:1002:1102=eng:1902:0:1227:169:3:0

 

TransEdit also has the same problem - see the screen capture attached.

Is it possible to use TransEdit capture the data from that transponder to a file so that I can upload it to enable it to be analyzed to see what the problem is?

support.zip

transedit_12519.jpg

Link to comment

I just installed a copy of the TransEdit 4.1.2 .exe file into my DVBViewer direcory and ran that.  It does find the channel names.

transedit-4.1.2_12519.jpg

Link to comment

It happens if the SDT (see here) can't be received. Possible reasons:

  • bad reception conditions
  • the SDT timeout is too short (see Settings -> Scanner in TransEdit)
  • the provider does not use the SDT in a DVB-compliant way, e.g. by broadcasting the channel and provider names of the actual transport stream in the SDT for other transport streams. TransEdit is able to auto-detect this issue (within limits) and to work around it.

Please use the TransEdit Analyzer to check what's going on.

 

Link to comment

Analyze is seeing the SDT just fine, but Scan is just not using the information.  The forum is not allowing me to attach the screen capture that shows this, so I have put it on my web server, along with a recording of the entire transponder for 30 seconds (120,569,288 bytes).  Using Scan and Analyze on the recorded data shows the problem.

 

http://www.jsw.gen.nz/DVBViewer/analyze_12519.jpg

http://www.jsw.gen.nz/DVBViewer/Optus_D1_160.0_-_SkyTV_NZ_transponders_12519_H_04-29_13-45-02.ts

Link to comment

There seems to be nothing wrong with the behavior of Transedit. All SI tables are read correctly. Take a look at the PAT and PMTs. All names from the SDT are assigned correctly.

But for several services the relating elementary streams are missing. There are no corresponds PIDs in the multiplex (e.g. SM Premiere).

Snap54.png

Link to comment

Jep, there's the bug. Another but empty TransportStreamID = 3 - 12519 MHz but with a different OriginalNetworkID = 105

 

Before I didn't perform a scan of the ts file. I've just looked at the analyzer ;)

Link to comment

It's caused by the algorithm that considers that the data may be located in the SDT for other transport streams (though according to the DVB specs it should be located in the SDT for the actual transport stream).

 

If TransEdit detects a section with a matching transport stream ID (3 = TS ID in the PAT) in the SDT for other transport streams, it sticks to it instead of ignoring it because it is empty. However, due to timing conditions it may also detect the corresponding section in the SDT for the actual TS first, yielding correct results

 

That's the problem with methods that are supposed to work around known faults of broadcasters... the may cause additional pitfalls.

 

1 hour ago, Derrick said:

but with a different OriginalNetworkID = 105

 

Irrelevant. After reading the PAT there is no Network ID that can be compared with the one from the SDT. The SDT is the only Network ID source for the scanner. So if the scanner finds a suitable SDT section (with the transport stream ID that equals the one from the PAT) there is no choice.

 

Anyway, the next TransEdit and DVBViewer bugfix releases.will ignore empty SDT sections and solve this particular problem.

 

Link to comment
Zitat

Irrelevant.

 

..maybe maybe not. Out of 3 scanners/analyzers transedit is the only one that shows this fault.

 

Zitat

If TransEdit detects a section with a matching transport stream ID (3 = TS ID in the PAT) in the SDT for other transport streams, it sticks to it instead of ignoring it because it is empty. However, due to timing conditions it may also detect the corresponding section in the SDT for the actual TS first, yielding correct results

 

I guess the table results should be processed in the correct logical sequence ;)

Link to comment
1 hour ago, Derrick said:

Out of 3 scanners/analyzers transedit is the only one that shows this fault.

 

It wouldn't if it didn't contain the work-around for our US friends. Now let's see where the measures for our NZ friend will cause which failure... :)

 

Link to comment
2 hours ago, Derrick said:

Out of 3 scanners/analyzers transedit is the only one that shows this fault.

 

I have now set up my test PC with my old DVB-S2 cards and finished adding support for my LNB to the Linux dvbv5-scan program, so I could test using that.  It also shows the same problem of not finding the channel names on the 12519 transponder.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...