Opened 19 years ago
Closed 18 years ago
#344 closed patch (fixed)
DVB EIT fails to insert event data into database
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.20 |
Component: | mythtv | Version: | head |
Severity: | low | Keywords: | DVB EIT |
Cc: | Ticket locked: | no |
Description
I'm currently testing with the latest devel-branch of mythtv (SVN 7265) with mythbackend -v channel,siparser,schedule options and with EIT_DEBUG_SID=49.
For some reason the DVB EIT fails to insert the retrieved short event descriptor data (0x4D) into the database. It does seem to get gathered up into Qmap (if I understand correctly), but after that it starts to loop with the "EventHandler::AddSection?" messages over and over again. To me it looks like everything would be just fine if the looping would end at some point and the gathered event data would be emitted to the database. However, the event handles logic seems little bit unclear to me.
I also tried to comment out the couple of lines of code in SIParser::ParseDescLinkage? in siparser.cpp (Kristian Kalweit problem) without success.
The log file is over 500KB's long and I've therefore stored it in http://ncircle.nullnet.fi/mythtv/eit.log .
Attachments (7)
Change History (27)
Changed 19 years ago by
Attachment: | eit.log.bz2 added |
---|
comment:1 Changed 19 years ago by
This is what I get too, my fix was to change this in mythtv/libs/libmythtv/siparser.cpp line ~1286
- x < ((head->section_number&0xF8)+8); x++)
+ x < ((head->section_number&0xF8)+32); x++)
I have asked on the list how this should be fixed "properly" but got no response. I also need the "Kristian Kalweit" fix.
I don't need either on my other provder, only the cable one.
comment:2 Changed 19 years ago by
Unfortunately this one-liner did not fix my problems with DVB EIT looping and not emitting anything into the database. I don't fully understand why not marking event slots as unused would result none of the events to be delivered ...
I tried the patch with and without the so called "Kristian Kalweit" fix, without success.
comment:3 Changed 19 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 Changed 19 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
my bad. typo'd a commit message.
Changed 18 years ago by
Attachment: | eit9.log.bz2 added |
---|
mythbackend (SVN7373) debug log with -v channel,siparser,schedule & #define EIT_DEBUG_SID 49
comment:5 Changed 18 years ago by
I have included an updated mythbackend debug log with -v siparser,channel,schedule created with SVN7373. It seems that the new EIT auto crawler code has not changed anything related to this particular bug ---> nothing is still being inserted into database, although EIT events are being read & parsed from the channels. The log messages from "EventHandler::AddSection?" seem to loop around for ever without completing (same channel all time long).
comment:6 Changed 18 years ago by
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | reopened → new |
comment:7 Changed 18 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Type: | defect → enhancement |
Until someone has a patch to add this feature, I'm closing the ticket.
There is some support for short descriptors, and hence the messages, but it is not complete. DVB EIT guide insertion currently requires long DVB EIT descriptors. If someone is interested in writing the code to make guide insertion work with short DVB EIT descriptors I'll review it. Make sure not to break things for people that have both long and short descriptors.
comment:8 Changed 18 years ago by
Daniel has asked me to try and look into this. Can you please update to the latest svn and retest, (to see if it's been fixed as part of something else). Failing that I'll try and help.
NB I don't have dvb-c and EIT just works for me so this could be a bit drawn out. I'll reopen the ticket once I/we get some response.
comment:9 Changed 18 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Sigh, still a problem it seems.
comment:10 Changed 18 years ago by
Milestone: | → 0.20 |
---|---|
Severity: | medium → low |
comment:11 Changed 18 years ago by
Could you apply the attached patch and post the logs please. It adds (lots) more debug to sitypes.cpp to hopefully give us a clue as to what's happening.
Changed 18 years ago by
Attachment: | mythbackend.log.bz2 added |
---|
Mythbackend log with John Pullan's EIT debug log patch (Warning, this is ridiculous in size when uncompressed ... 40MB)
comment:12 Changed 18 years ago by
John,
It looks like your debug patch did find something interesting from the EIT event handling. It does seem to print "tracker not setup" over and over again for this particular service id.
comment:13 Changed 18 years ago by
Hmm, I forgot to add that the event-handling in this particular cable-bnetwork is not totally "dead", ie. the system DOES pickup EIT information for some channels every once in a while, it just doesn't seem to work consistently all the time. For example right now the problematic channels have only a few days of worth of EIT information, while a different mux seems to be able to gather up 7 days of events.
The overall behaviour has changed in some ways, because a couple of weeks ago there was absolutely no events available by mythtv for any mux. Perhaps the recent PMT changes did change something, although not everything is working properly at the moment.
comment:14 Changed 18 years ago by
Could you please try this patch.
Provides possible fix Change to the debug patch Fix to the "no services" debug (ahem) Remove references to tracker not being setup
Changed 18 years ago by
Attachment: | mythbackend.log.2.bz2 added |
---|
Mythbackend debug log with eit.2.patch and EIT_DEBUG_SID 49
comment:15 Changed 18 years ago by
Thanks John,
Don't know what the debug log exactly tells you, but to me it looks like the system is not looping anymore! And it looks like the system does have the full (7 days worth of ) EIT-information for all of the currently tuned channels.
comment:16 Changed 18 years ago by
Type: | enhancement → patch |
---|
The last version of the patch addresses two issues
1) Pulling wasn't being set. 2) Even if it were set, there was a large chance on non UK transmitters that only the first table for a service id was being emitted. If a provider sent all of table 0x50 followed by all of table 0x51 then because table 0x50 filled up it's sections first we would emit it but mark the entire channel as being updated. Table 0x51 would then arrive and fill up, but would never be emitted.
comment:17 Changed 18 years ago by
comment:18 Changed 18 years ago by
Type: | patch → enhancement |
---|
I wonder if this issue could be also be affected by the data sections never being delivered. The thread
http://www.linuxtv.org/pipermail/linux-dvb/2005-September/004914.html
discusses the fact that very small or very large sections that closely follow each other could be lost. This is apparently a situation that can occur quite a bit with DSMCC, EIT and other data streams.
The thread continues in October
http://www.linuxtv.org/pipermail/linux-dvb/2005-October/005540.html
comment:19 Changed 18 years ago by
Type: | enhancement → patch |
---|
That last comment wasn't supposed to change the type
Copy of the above mentioned DVB EIT debug log with -v channel,siparser,schedule & #define EIT_DEBUG_SID 49