Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1705 closed patch (fixed)

RunTableMonitorTS overwrites occasionally a tspacket with uninitialized data

Reported by: Janne <janne-mythtv@…> Owned by: danielk
Priority: minor Milestone: 0.20
Component: dvb Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

If the read in RunTableMonitorTS reads 188 bytes not starting with a sync byte, ProcessData? cant process it and returns 188 as remainding bytes.

An error in the memmove overwrites this packet with garbage from the end of the uninitialized buffer. Tuning works only if the read returns more than 188 bytes.

Attached patch fixes this.

Attachments (1)

dvbsignalmonitor_fix.patch (592 bytes) - added by Janne <janne-mythtv@…> 13 years ago.

Download all attachments as: .zip

Change History (10)

Changed 13 years ago by Janne <janne-mythtv@…>

Attachment: dvbsignalmonitor_fix.patch added

comment:1 Changed 13 years ago by Janne <janne-mythtv@…>

please apply also to 0.19-fixes

comment:2 Changed 13 years ago by tino.keitel+mythtv@…

Hi,

I can confirm that this patch solves my endless trouble with unreliable channel switching and failed recordings with my old style Hauppauge Nova-T PCI.

Thanks a lot!

comment:3 Changed 13 years ago by danielk

Milestone: 0.20
Version: head

Janne can you analyse this a bit more, from my reading of the code this particular case of a 188 byte unsynced read should work ok.

Is it perhaps a smaller read that is failing?

comment:4 Changed 13 years ago by Janne <janne-mythtv@…>

Daniel, Have you look at the patch? Currently the code copies remainder bytes from the end of the buffer and not from the end of the readed data.

Tuning works in my case only if 376 or more bytes are read. With a initial read of 188 bytes ProcessData? returns 188 bytes since it can't resync the stream. And then the memmove writes uninitialized data from the end of the buffer over the just readed data. The next read of 188 bytes can't synchronized too since we have deleted the sync byte in the first chunk. And so on until we read more than 188 bytes.

comment:5 Changed 13 years ago by Stuart Auchterlonie

Daniel,

We looked carefully at this on IRC and it is correct.

comment:6 Changed 13 years ago by danielk

(In [9745]) References #1705. Fixes the problem Janne discovered in several files.

I'll be backporting this to 0.19-fixes.

comment:7 Changed 13 years ago by danielk

Resolution: fixed
Status: newclosed

(In [9746]) Closes #1705. Fixes the handling of short reads when reading transport streams from a device.

comment:8 Changed 13 years ago by danielk

(In [9747]) References #1705. Fixes another instance of the improper handling of short reads when reading transport streams from a device.

comment:9 Changed 13 years ago by danielk

(In [9748]) References #1705. Fixes another instance of the improper handling of short reads when reading transport streams from a device in 0.19-fixes.

Note: See TracTickets for help on using tickets.