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: | 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)
Change History (10)
by , 20 years ago
Attachment: | dvbsignalmonitor_fix.patch added |
---|
comment:1 by , 20 years ago
comment:2 by , 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 , 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 , 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:6 by , 20 years ago
comment:7 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
please apply also to 0.19-fixes