Opened 20 years ago

Closed 20 years ago

Last modified 20 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@…> 20 years ago.

Download all attachments as: .zip

Change History (10)

by Janne <janne-mythtv@…>, 20 years ago

Attachment: dvbsignalmonitor_fix.patch added

comment:1 by Janne <janne-mythtv@…>, 20 years ago

please apply also to 0.19-fixes

comment:2 by tino.keitel+mythtv@…, 20 years ago

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 by danielk, 20 years ago

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 by Janne <janne-mythtv@…>, 20 years ago

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 by Stuart Auchterlonie, 20 years ago

Daniel,

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

comment:6 by danielk, 20 years ago

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

I'll be backporting this to 0.19-fixes.

comment:7 by danielk, 20 years ago

Resolution: fixed
Status: newclosed

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

comment:8 by danielk, 20 years ago

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

comment:9 by danielk, 20 years ago

(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.