new DVB-T in Poland: SDT seen but not good

[warped <warpme@…>]

HI, Recently here in Poland 2-nd DVB-T mplex was launched. I'm able to scan it and find programs but unable to decode them. Signal monitor constantly shows TLMs. This AFAIK means SDT table was seen but is incorrect. I went to some discussion forums and many ppl reporting successful reception of this mplex on various TVs/STBs. It looks like there is more subtle incapability between myth and this particullar mplex. Log from BE with channel,record attached.

[warped <warpme@…>]

log from tuning/recording process

[warpme@…]

Hi,

Is there any chance to move forward with this ticket ? How can I help for making progress ?

[robertm]

warpme, you have opened many many tickets, you are expeted to know the contents of the ticket howto.

[robertm]

More Debug for SDT Status

[robertm]

Can you please apply this patch and provide a new log with -v channel, record?

Thanks.

[warped <warpme@…>]

Robert,

Thx for picking-up this bug. Pls find log from LiveTV attempts on those 2 bad multiplexes. I'm on master g4d4eaa8. br

[warped <warpme@…>]

Log with sdt diff

[robertm]

Please also apply this patch and provide more logs. Thanks.

[warped <warpme@…>]

Robert, Unfortunately with this patch I can't compile. Compiler output attached.

[robertm]

Sorry, try this one. Should compile okay.

[warped <warpme@…>]

Thx. Pls find log1.txt with this patch applied.

[robertm]

Hi warped, Sorry to drag you around like this, but can you please update to current master and just apply this last patch (allgooddebug.3.diff)? I'm attempting to get this debug info from you while I'm at work, which makes testing my debug patches hard. This last one should do it, though.

[robertm]

Heh, never mind, I guess the last one worked ... but the debug info I was looking for isn't there. Stand by.

[robertm]

Hi warped,

It was (correctly) pointed out to me that the logging turned on will go to stderr-- if you are capturing the log with -l or >, can you please also post the output to the console that doesn't make it to the log, or redirect stderr to the file too?

mythfrontend &> logfile.log

should work.

[warped <warpme@…>]

Robert,

logfile.log is log from BE launched via following cmd line

su mythtv -c "/usr/bin/mythbackend --verbose channel,record &> /var/log/logfile.log"

[robertm]

This is the world's stupidest patch, and shouldn't be run long term, but try it and see if the result is working TV.

diff --git a/mythtv/libs/libmythtv/dtvsignalmonitor.cpp b/mythtv/libs/libmythtv/dtvsignalmonitor.cpp
index 552d4d1..3675dce 100644
--- a/mythtv/libs/libmythtv/dtvsignalmonitor.cpp
+++ b/mythtv/libs/libmythtv/dtvsignalmonitor.cpp
@@ -152,7 +152,7 @@ void DTVSignalMonitor::UpdateMonitorValues(void)
     matchingMGT.SetValue((flags & kDTVSigMon_MGTMatch) ? 1 : 0);
     matchingVCT.SetValue((flags & kDTVSigMon_VCTMatch) ? 1 : 0);
     matchingNIT.SetValue((flags & kDTVSigMon_NITMatch) ? 1 : 0);
-    matchingSDT.SetValue((flags & kDTVSigMon_SDTMatch) ? 1 : 0);
+    matchingSDT.SetValue((flags & kDTVSigMon_SDTMatch) ? 1 : 1);
     matchingCrypt.SetValue((flags & kDTVSigMon_CryptMatch) ? 1 : 0);
 }
 

[warped <warpme@…>]

Robert, Quick report: both muxes now are working. On one of them there is 5 progs and selecting different progs sometimes stays on the same prog. I'm not sure is mplex scanned with all actual SIDs - so tomorrow I will look more closely. May You be so kind and give me some context for this patch. Thx !!!!

[robertm]

The patch short circuits the matching logic for SDTs and thus any seen SDT will be a match. This hack is almost definitely the reason for the fact that it sometimes remains the same (and might even sometimes change to the wrong channel on the mux). The conclusion I draw from it is that either the muxes are very incorrectly engineered, or our SDT parsing/matching logic is broken somewhere.

I would not continue to run this patch for very long as it will cause tuning problems.

[warped <warpme@…>]

Robert, Thx. I see some possibilities to influence mux broadcasters to look into headend mux configs - but for this, problem understanding is crucial. Your explanation good starting point to full understanding problem (dvb-snoop will be my friend). I will look into situation in my idle threads - so probably in next weeks/months we will know more. Patch can be private one - so we will not sacrifice myth code quality because some ppl in Poland needs more learning ;-p. Last thing: may You hint me about nature of potential issues with tuning problems ? Thx in advance !

[robertm]

Warped, I think I am starting to see the issue here. Please apply this patch and give me another set of logs.

diff --git a/mythtv/libs/libmythtv/dtvsignalmonitor.cpp b/mythtv/libs/libmythtv/dtvsignalmonitor.cpp
index 552d4d1..55e1c91 100644
--- a/mythtv/libs/libmythtv/dtvsignalmonitor.cpp
+++ b/mythtv/libs/libmythtv/dtvsignalmonitor.cpp
@@ -454,6 +454,9 @@ void DTVSignalMonitor::HandleSDT(uint, const ServiceDescriptionTable *sdt)
     detectedNetworkID = sdt->OriginalNetworkID();
     detectedTransportID = sdt->TSID();
 
+    DBG_SM("HandleSDT()", QString("networkID = %1 orig_net_id = %2 transportID = %3 orig_transport_id = %4")
+               .arg(networkID).arg(sdt->OriginalNetworkID()).arg(transportID).arg(sdt->TSID()));
+
     if (sdt->OriginalNetworkID() != networkID || sdt->TSID() != transportID)
     {
         GetDVBStreamData()->SetVersionSDT(sdt->TSID(), -1, 0);

[robertm]

And also please provide the output from:

SELECT * from videosource;

from your database. If there is any password data there, feel free to remove it. Thanks.

[warped <warpme@…>]

Robert, Compiling now. FYI: I'm using also SAT and for correct PL chars in EPG I applied patch from ticket9480. Hope it has nothing common with our issue...

[warped <warpme@…>]

Hi,

I'm attaching videosource (CSV format from SequelPro? on MAC) and BE logs (logfile1.log)

[warped <warpme@…>]

Hmm - last attachment blocked as I exceed number of allowed uploaded files per hour. videosource pasted here: sourceid,"name","xmltvgrabber","userid","freqtable","lineupid","password",useeit,"configpath",dvb_nit_id 9,"DVB-T","/bin/true","","default",NULL,NULL,0,NULL,-1 8,"Cyfra","eitonly","","default",NULL,NULL,1,NULL,-1

[robertm]

warped, you need to remove the patch from ​http://code.mythtv.org/trac/ticket/9278#comment:15 before getting me logs. The above aren't useful with the hack applied.

[warped <warpme@…>]

Robert, Hre is logfile2.log from be without #15 patch

[warped <warpme@…>]

Robert,

FYI: Per last log as POC I changed TSids in mplexes to values reported by log (13400->12 & 1->3). Now those 2 mplexes are working without SDT patch #15 - so in my opinion it looks like 1\DVB scanner by bug continuously picking wrong values during scan (I rescanned many times) or those 2 mplexes have something wrong in structure leading scanner to picking wrong TSID values.

[robertm]

If this is a scanner issue (and I beleive it could be), then to solve it I need to see a channelscan on a *fresh video source* with -v channelscan,record,siparser

[warped <warpme@…>]

Robert,

I'm in middle of long term stability tests (2.6.38.8 has some changes in cx88 sud-dev locking which highly probably causes decreased system stability for me). I will try do fresh scan at weekend.... br

[robertm]

No response.

[warpme@…]

Robert, Forgive me silence here. It is not result of ignorance but rather effect of changes in my receiving system. I temporarily had to switch-off DVB-T due issues with cabling (house developer screwed instalation and now for return to DVB-T I have to do cables reinstall :-((( )