Feature #3030
False services
0%
Description
I still have a lot of issues with "false services" added and I need to remove a lot of "empty" lines every day. I using TBS and their drivers. I have been in contact with TBS and they say:
"The reason is TVH starts scanning very fast after signal lock. so, there is not enough time the buffer in the driver be filled entirely with the new data. so, last week i promised another user to prepare few test drivers with different buffer sizes - basically with trial and error we find some buffer in-the-middle as size that gives reliable data-transfer from the card and at the same time is small enough to be filled before TVH starts scanning after signal-lock is acquired. IMHO, application software like TVH should provide way to set how much time after signal lock is present to start scanning or capturing, but that's another story. anyway, i am going to send you the test drivers tomorrow, when i scheduled to send them to the other user too"
Is there any possibilty to have some improvements in tvh also in this matter ??
History
Updated by Mark Clarkstone over 9 years ago
Bengt Madeberg wrote:
I still have a lot of issues with "false services" added and I need to remove a lot of "empty" lines every day. I using TBS and their drivers. I have been in contact with TBS and they say:
"The reason is TVH starts scanning very fast after signal lock. so, there is not enough time the buffer in the driver be filled entirely with the new data. so, last week i promised another user to prepare few test drivers with different buffer sizes - basically with trial and error we find some buffer in-the-middle as size that gives reliable data-transfer from the card and at the same time is small enough to be filled before TVH starts scanning after signal-lock is acquired. IMHO, application software like TVH should provide way to set how much time after signal lock is present to start scanning or capturing, but that's another story. anyway, i am going to send you the test drivers tomorrow, when i scheduled to send them to the other user too"
Is there any possibilty to have some improvements in tvh also in this matter ??
Have you tried increasing the following options?
Skip Initial Bytes : If set, the first bytes from the MPEG-TS stream are discarded. It may be required for some drivers or hardware which do not flush completely the MPEG-TS buffers after a frequency/parameter change. Input Buffer (Bytes) : By default, linuxdvb's input buffer is 18800 bytes long. The accepted range is 18800-1880000 bytes.
This requires the latest master though.
Updated by Bengt Madeberg over 9 years ago
Ok, thanks . I will do some tests. I have no idea which values to use so it will be "cut and try"...
Updated by Bengt Madeberg over 9 years ago
Ok, I have not done any extensive testing but "Skip Initial Bytes" of 48128 seems to solve the problem for me. This request can be closed.
Updated by Mark Clarkstone over 9 years ago
Bengt Madeberg wrote:
Ok, I have not done any extensive testing but "Skip Initial Bytes" of 48128 seems to solve the problem for me. This request can be closed.
Glad to hear you got it working properly in the end, I'm quite surprised TBS didn't mention the Skip Initial Bytes option looks like they might be using an older version without it..
I believe perexg added these options as a work around for poorly written drivers..
I'm not sure what TBS card you have but you might want to give ljalves drivers a go instead of the TBS ones if your card is supported.
Updated by Bengt Madeberg over 9 years ago
Maybe I should also mention that if I change it "skip ..." too many times it seems that the new values will not be activated properly, added to the old ones !?. The channel switching takes longer and longer time. Even if I put it back to "0" it will not help. The only way to restore it is to restart tvh...