Bug #249
closed
Transponder quality detected at 100%, but no services are detected
Added by satfan39 - over 14 years ago. Updated over 12 years ago.
0%
Description
On Hotbird 13E, 11,240 Ghz, mux gets detected ok at 100% quality but no services shows up in the list. Frontend is indicated as unknown
The services transmitted on that mux uses DVB-S, QPSK and MPEG4
I also Tested this with Kaffeine and mythtv and I have no issues to detect those services during the scan, so it must be tvheadend.
Tested with a DVB-S card (BTxxx ) and without installing s2api.
Files
Updated by Andreas Smas over 14 years ago
I need a mux dump to figure something out here...
Updated by Magnus Pfeffer over 14 years ago
satfan39 - wrote:
On Hotbird 13E, 11,240 Ghz, mux gets detected ok at 100% quality but no services shows up in the list. Frontend is indicated as unknown
I noticed the same. In my case, the frontend status is "OK". I use a TT-3600 USB DVB-S2 receiver.
The same also happens on Hotbird 13E, 11,179 GHz (Telespazio). The mux is properly detected, but no services are found.
I would like to help with this bug, and would provide stream dumps if I can get a pointer how to create one.
Keep up the good work,
Magnus
Updated by Magnus Pfeffer over 14 years ago
Hi,
I googled, learned about dvbstream and recorded a full TS dump of the offending MUX:
root@blackhole:/mnt/raid/hts# dvbstream -o:file.ts -n 5 -D 0 -f 11179000 -s 27500 -p H 8192
dvbstream v0.7 - (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://www.linuxstb.org/
Adding whole transport stream to map n. 0
Open file file.ts
Tuning to 11179000 Hz
Using DVB card "STB0899 Multistandard", freq=11179000
tuning DVB-S to Freq: 1429000, Pol:H Srate=27500000, 22kHz tone=off, LNB: 0, SLOF 11700, LOF1: 9750, LOF2: 10600
Setting only tone OFF and voltage 18V
DISEQC SETTING SUCCEDED
Getting frontend status
Event: Frequency: 11179000
SymbolRate: 27500000
FEC_inner: 9
Bit error rate: 0
Signal strength: 403
SNR: 151
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
MAP 0, file file.ts: From -1 secs, To -1 secs, 2 PIDs - 0 8192
dvbstream will stop after -1 seconds (71582788 minutes)
Streaming 1 stream
Program n. 4908, name: 'TV MODA'
Program n. 4910, name: 'TELEPADREPIO'
Program n. 4912, name: 'TEF CHANNEL'
Program n. 4913, name: 'TELELOTTO'
Program n. 4915, name: 'Studio Europa'
Program n. 4916, name: 'GLOBE MEDIA'
Program n. 4917, name: 'Challenger'
Program n. 4918, name: 'Telefoggia'
Program n. 4919, name: 'Free Channel'
Program n. 4920, name: 'New Television'
Program n. 4921, name: 'GBR'
Program n. 4922, name: 'Cancao Nova Interna'
Program n. 4925, name: 'TRSP'
Program n. 4926, name: 'Moto TV'
Program n. 4927, name: 'Telemarket'
Program n. 4928, name: 'ERDE UND MENSCH'
Program n. 4929, name: 'Italia 8'
Program n. 4930, name: 'Al-Anwar'
Program n. 4931, name: 'Payam-E-Afghan'
Program n. 4932, name: 'NTD TV'
Program n. 4933, name: 'Imam Hussein TV'
Program n. 4934, name: 'Armenia TV'
Program n. 4936, name: 'VAB RADIO'
^CCaught signal 2 - closing cleanly.
I am using TVHeadend V2.12
Updated by Magnus Pfeffer over 14 years ago
Hi,
and here the dump for the mux in the original bug report.
root@blackhole:/mnt/raid/hts# dvbstream -o:file2.ts -n 5 -D 0 -f 11240000 -s 27500 -p V 8192
dvbstream v0.7 - (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://www.linuxstb.org/
Adding whole transport stream to map n. 0
Open file file2.ts
Tuning to 11240000 Hz
Using DVB card "STB0899 Multistandard", freq=11240000
tuning DVB-S to Freq: 1490000, Pol:V Srate=27500000, 22kHz tone=off, LNB: 0, SLOF 11700, LOF1: 9750, LOF2: 10600
Setting only tone OFF and voltage 13V
DISEQC SETTING SUCCEDED
Getting frontend status
Event: Frequency: 11240000
SymbolRate: 27500000
FEC_inner: 9
Bit error rate: 0
Signal strength: 403
SNR: 137
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
MAP 0, file file2.ts: From -1 secs, To -1 secs, 2 PIDs - 0 8192
dvbstream will stop after -1 seconds (71582788 minutes)
Streaming 1 stream
Program n. 13876, name: 'Disney Channel'
Program n. 13877, name: 'ESP2 NE Intl'
Program n. 13878, name: 'ESP2 NE Polish'
Program n. 13879, name: 'ESP2 NE Bulgarian'
Program n. 13880, name: 'ESP2 NE Serbian'
Program n. 13881, name: 'ESP2 NE Czech'
Program n. 13882, name: 'ESP2 NE Danish'
Program n. 13883, name: 'ESP2 NE Russian'
Program n. 13884, name: 'ESP2 NE Swedish'
Program n. 13885, name: 'ESP ECH'
Program n. 13886, name: 'ESP2 NE UPC'
Program n. 13887, name: 'ESP2 NE Hungary'
Program n. 13888, name: 'ESP2 NE Romania'
Program n. 13889, name: 'ESP UPC'
^CCaught signal 2 - closing cleanly.
root@blackhole:/mnt/raid/hts#
Updated by Magnus Pfeffer over 14 years ago
Hi,
as maybe a 4 MB dump is insufficient to debug this issue, I created a larger TS dump of the Hotbird 13E, 11179000 vertical mux.
You can download it here (75M):
Updated by Magnus Pfeffer over 14 years ago
Hi,
this bug is actually a regression. The services on both problematic Hotbird 13E muxes are detected fine with tvheadend 2.10. I will test 2.11 next and report.
Can you tell me with part of the code is responsible for service detection? I do know some C/C++ basics, but have never learned how to properly debug in C/C++. If I knew the function/files in question, I should be able to replay the relevant git commits to find the one that introduced the error.
Greetings,
Magnus
Updated by Magnus Pfeffer over 14 years ago
Hi,
some further testing reveals that this bug is somehow caused by interaction between the transponder list that is hardcoded in src/linuxtv_muxes.h, automatic mux discovery and the idle scanning process.
If "Add DVB Network by location" in the configuration tab is used, the mux list will be populated with these preset muxes, but automatic mux discovery will then re-add several of them with slightly different (most probably the exact) frequencies.
Tvheadend will in some - but not all - cases fail to find services for both the correct and the preloaded mux if both are present in the mux list. Apparently scanning fails once two or more transponders with the same muxid are in the list at the time of the scan.
Even without the incorrect preloaded list of transponders, automatic mux discovery will find the same transponder with several (slightly) different frequencies. This is most likely the root cause for the buggy behaviour. I will document the results for 13E and file a seperate issue.
Updated by Adam Sutton over 12 years ago
- Status changed from New to Rejected
- Found in version set to unknown
I'm going to close this on the grounds that its old, and might now have a duplicate.
However if its still an issue please do re-submit.