Opened 18 years ago
Closed 18 years ago
#1790 closed defect (fixed)
pes packet assembly in mythtv-eit
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.20 |
Component: | dvb | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
atached patches fix the issues not entirely
Attachments (11)
Change History (24)
Changed 18 years ago by
Attachment: | crc_check_verbose.diff added |
---|
Changed 18 years ago by
Attachment: | ignore_crc_for_unassembled_pespackets.diff added |
---|
don't do a CRC check if the packet is incomplete
Changed 18 years ago by
Attachment: | pes_assembly_robustness.diff added |
---|
adds checks in AssemblePSIP to avoid processing invalid data
comment:1 Changed 18 years ago by
comment:2 Changed 18 years ago by
comment:3 Changed 18 years ago by
Milestone: | → 0.20 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
This should have been closed by [9897] which applied a portion of the last patch on this ticket.
comment:4 Changed 18 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
[9897] may not work with buggy dvb cards
the second patch fixes hopefully the issues of the pes packet assembly.
I see occasionally failed CRC checks and discarded packets. I'm not sure if they are only caused by reception errors, especially since I see "AddTSPacket: Out of sync!!! Need to wait for next payloadstart" in bursts.
Changed 18 years ago by
Attachment: | buggy_dvb_cards_fix.diff added |
---|
may fix issues with buggy dvb cards in [9897]
Changed 18 years ago by
Attachment: | pes_assembly_pesdata_fix.diff added |
---|
reset the pointer to pesdata after copying the buffer
comment:5 Changed 18 years ago by
comment:6 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:7 Changed 18 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Daniel, this still isn't working for me. I have two providers. One is working, the other not. Dvbsnoop shows a valid SDT for both. I'm attaching two backend logs for your viewing pleasure.
comment:8 Changed 18 years ago by
Please attach the output of "dvbsnoop -n 5 -crc 0x11".
Please provide backend logs from runs with following verbose options: channel,record,siparser if they differ the options you used.
comment:9 Changed 18 years ago by
The logs provided have those verbose options exactly. Dvbsnoops attached.
comment:10 Changed 18 years ago by
Ok, does the provider transmit a SDT?
Please try dvbsnoop -n 1 -m 0xFF -f 0x42 0x11.
comment:12 Changed 18 years ago by
Ok, after speaking at length with Janne (thanks Janne for your patients), it seems my provider's SDT's tableid 0x42 doesn't at all contain current transport service definitions. Therefore, for me, depending on this table for tuning is a bad thing. the only other table we could use is the NIT tableid 0x40 but then we'd have to compare on network_id instead of original_network_id. May I suggest either a global backend option, or better yet, a per-transport option which tells the tuning methods to ignore the SDT?
But that leaves the problem in mpegstreamdata which ignores redundant PATs. If we're not resetting the version number when we know we've seen the correct networkid, then it will never get reset and tuning will fail.
If I hack the code to reparse the PAT until a valid PAT is seen, then my tuning is ~100% in trunk.
comment:13 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Version: | → head |
Mark, have you tried zeroing out the transportid and networkid in the dtv_multiplex table for this channel? That should force MythTV ignore the SDT table.
PS please respond in mythtv-dev.
adds verbose output of streamid to ease debugging