Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#9278 closed Bug Report (Invalid)

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

Reported by: warped <warpme@…> Owned by: Janne Grunau
Priority: minor Milestone: unknown
Component: MythTV - Channel Scanner Version: 0.24-fixes
Severity: medium Keywords:
Cc: Stuart Auchterlonie Ticket locked: no

Description

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.

Attachments (11)

dvb-t.log (13.9 KB) - added by warped <warpme@…> 9 years ago.
log from tuning/recording process
sdtstatus.diff (830 bytes) - added by robertm 8 years ago.
More Debug for SDT Status
log.txt (181.7 KB) - added by warped <warpme@…> 8 years ago.
Log with sdt diff
allgooddebug.diff (700 bytes) - added by robertm 8 years ago.
compile_abort.txt (19.2 KB) - added by warped <warpme@…> 8 years ago.
allgooddebug.2.diff (1.0 KB) - added by robertm 8 years ago.
log1.txt (127.2 KB) - added by warped <warpme@…> 8 years ago.
allgooddebug.3.diff (701 bytes) - added by robertm 8 years ago.
logfile.log (91.3 KB) - added by warped <warpme@…> 8 years ago.
logfile1.log (67.9 KB) - added by warped <warpme@…> 8 years ago.
logfile2.log (55.9 KB) - added by warped <warpme@…> 8 years ago.

Download all attachments as: .zip

Change History (41)

Changed 9 years ago by warped <warpme@…>

Attachment: dvb-t.log added

log from tuning/recording process

comment:1 Changed 9 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

comment:2 Changed 8 years ago by Kenni Lund [kenni a kelu dot dk]

Component: MythTV - RecordingMythTV - DVB
Owner: changed from danielk to Janne Grunau
Status: newassigned

comment:3 in reply to:  2 Changed 8 years ago by warpme@…

Hi,

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

comment:4 Changed 8 years ago by robertm

Ticket locked: set

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

Changed 8 years ago by robertm

Attachment: sdtstatus.diff added

More Debug for SDT Status

comment:5 Changed 8 years ago by robertm

Status: assignedinfoneeded
Ticket locked: unset

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

Thanks.

comment:6 Changed 8 years ago by 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

Changed 8 years ago by warped <warpme@…>

Attachment: log.txt added

Log with sdt diff

Changed 8 years ago by robertm

Attachment: allgooddebug.diff added

comment:7 Changed 8 years ago by robertm

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

comment:8 Changed 8 years ago by warped <warpme@…>

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

Changed 8 years ago by warped <warpme@…>

Attachment: compile_abort.txt added

Changed 8 years ago by robertm

Attachment: allgooddebug.2.diff added

comment:9 Changed 8 years ago by robertm

Sorry, try this one. Should compile okay.

comment:10 Changed 8 years ago by warped <warpme@…>

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

Changed 8 years ago by warped <warpme@…>

Attachment: log1.txt added

Changed 8 years ago by robertm

Attachment: allgooddebug.3.diff added

comment:11 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by robertm

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

comment:13 Changed 8 years ago 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.

comment:14 Changed 8 years ago by 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"

Changed 8 years ago by warped <warpme@…>

Attachment: logfile.log added

comment:15 Changed 8 years ago by 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);
 }
 

comment:16 Changed 8 years ago by 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 !!!!

comment:17 Changed 8 years ago by robertm

Status: infoneededassigned

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.

comment:18 Changed 8 years ago by 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 !

comment:19 Changed 8 years ago by robertm

Status: assignedinfoneeded

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);

comment:20 Changed 8 years ago by 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.

comment:21 Changed 8 years ago by 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...

comment:22 Changed 8 years ago by warped <warpme@…>

Hi,

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

Changed 8 years ago by warped <warpme@…>

Attachment: logfile1.log added

comment:23 Changed 8 years ago by 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

comment:24 Changed 8 years ago by 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.

comment:25 Changed 8 years ago by warped <warpme@…>

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

Changed 8 years ago by warped <warpme@…>

Attachment: logfile2.log added

comment:26 Changed 8 years ago by 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.

comment:27 Changed 8 years ago by robertm

Component: MythTV - DVBMythTV - Channel Scanner

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

comment:28 Changed 8 years ago by 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

comment:29 Changed 8 years ago by robertm

Resolution: Invalid
Status: infoneededclosed

No response.

comment:30 Changed 8 years ago by 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 :-((( )

Note: See TracTickets for help on using tickets.