Moderator Control Panel ]

Getting bad timings in TVHeadEnd with TBS6905 (SOLVED)

Getting bad timings in TVHeadEnd with TBS6905 (SOLVED)

Postby cband » Mon Jul 06, 2015 11:46 am

As I mentioned in a previous post, I have a system that contains a TBS6985, a TBS6991SE, and a newly-added TBS6905 to give me ten tuners in all. The older tuners were working fine in TVHeadEnd and still do, however the TBS6905 seems to give intermittent timing errors on recordings. For example, tonight I recorded a one hour program off of a DVB-S2 source (C-band dish) and TVHeadEnd reports the program as 9 hours and 40 minutes in length, even though it only recorded for the hour. When this type of error happens, you cannot skip around within the program in the usual manner; if you try to use the forward or reverse skip it either takes forever to find the new location or worse yet, it throws you back to the very start of the recording so the only thing you can do is start watching over from the beginning. When the same LNB is connected to one of the older TBS cards I never see this issue, it is only the TBS6905 that seems to have this problem. Is there any chance the TBS6905 could be defective, or is there any way to fix this issue?
Last edited by cband on Wed Aug 05, 2015 12:01 am, edited 1 time in total.
cband
 
Posts: 16
Joined: Sun Aug 24, 2014 4:46 pm

Re: Getting bad timings in TVHeadEnd with TBS6905

Postby cody » Thu Jul 09, 2015 12:48 am

what you set as recoding type in your TVH? in any way, i suggest for test purposes and investigation of the problem to set it to TS.

then if when you play that TS the problem you described has occurred, you can try something like:

Code: Select All Code
dd if=capture.ts of=output.ts bs=188*8*1024 skip=1 count=1


which will remove first and last 1MB of TS packets from the file and save the new file to "output.ts". if that doesn't fix it and "output.ts" still shows wrong time, you can delete it and repeat the same with cutting more with "skip=2 count=2", etc. i am asking you to do such test, because i suspect that maybe at the beginning or end of the recording there could be few bad bytes that makes the player display wrong time.

in fact for a fast test you can try something extreme - like cutting 100MB (assuming your TS recording is over 200 MB) with "skip=70 count=70". so, DVB card and drivers do not change the TS packets. that means if such test doesn't help and the problem is not in the beginning or the end, then there is no chance it's related to the drivers. it's possible at beginning and the end due to timing problem some data got corrupted - TVH saves the data faster than the driver send them to the data buffers. if that's confirmed what can be done is we reduce the size of the buffers, that way reduce such latency that can cause such timing problem.
cody
 
Posts: 627
Joined: Tue Apr 13, 2010 11:20 pm

Re: Getting bad timings in TVHeadEnd with TBS6905

Postby cband » Thu Jul 09, 2015 11:02 pm

Thanks for your help. I've never used anything but TS. All of my Recording - DVR profiles are set to use the PASS stream profile, which I am told pretty much copies the stream directly to the storage device, and the resulting recordings all have the .ts extension.

I will try the test you mentioned next time I get a bad recording. Of course when you want to get one with bad timing so you can run a test on it, they all record perfectly! :? I'm sure it's only a matter of time until I get another one with this issue; I couldn't be lucky enough that the issue magically fixed itself. So when it happens again I'll try that dd command and post the result.
cband
 
Posts: 16
Joined: Sun Aug 24, 2014 4:46 pm

Re: Getting bad timings in TVHeadEnd with TBS6905

Postby cband » Fri Jul 10, 2015 2:18 pm

cody: I had two bad recordings today, both one hour long programs. When I tried to run the command you gave (substituting actual filenames) it gave me this error:

dd: invalid number `188*8*1024'

I'm not all that proficient in Linux so I typed "dd --help" and learned that the bs value sets a block size. So just for the heck of it I tried specifying "bs=10G" since I figured that should copy the whole file, but it didn't. Instead it said:

0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 37.1445 s, 57.8 MB/s

So it only got a part of the file. It turned out it was a segment of just over 8 minutes but I could skip around in it with no problems. However it was clearly not from the start of the program.

Since you talked about cutting the first 1 MB from the start, I then tried using the options "bs=1M skip=1 count=999999999" with the goal of getting the entire program except for the first 1MB. This returned:

16309+1 records in
16309+1 records out
17101800224 bytes (17 GB) copied, 326.141 s, 52.4 MB/s

And did indeed produce a file 1 MB shorter than the original. The new file had the correct time and I was able to skip around in it with no problem whatsoever. I repeated that operation on the other bad recording, and the newly created file on that one also played like any normal recording, and I could skip around in it. If I am understanding the dd command options correctly, the ONLY difference was that I skipped the first 1 MB of the original file (and NOTHING at the end because of the outrageously high count value specified, which I'm assuming specified more blocks than the file contained).

You wrote,

cody Wrote:it's possible at beginning and the end due to timing problem some data got corrupted - TVH saves the data faster than the driver send them to the data buffers. if that's confirmed what can be done is we reduce the size of the buffers, that way reduce such latency that can cause such timing problem.


It does seem that skipping the first 1 MB eliminated the problem in at least two tests, so if that gives you enough information to go on I would very much appreciate it if this problem could be fixed in some way. If you need me to run any additional tests, please let me know, but please keep in mind that the dd option "bs=188*8*1024" doesn't seem to work in the version of dd on my system.
cband
 
Posts: 16
Joined: Sun Aug 24, 2014 4:46 pm

Re: Getting bad timings in TVHeadEnd with TBS6905

Postby cband » Sun Jul 19, 2015 11:01 am

Hi. Haven't heard anything since my last post and this problem still exists so was wondering if you are going to try and do any kind of fix in the drivers? For what it's worth, I upgraded TVHeadEnd today and that didn't help - still got a bad recording tonight, and using dd to chop off the first 1M of the file fixed it again.
cband
 
Posts: 16
Joined: Sun Aug 24, 2014 4:46 pm

Re: Getting bad timings in TVHeadEnd with TBS6905

Postby cband » Tue Jul 28, 2015 3:49 am

For anyone else experiencing this issue, I'm now testing the following fix in TVHeadEnd, setting a "Skip Initial Bytes" value for each TBS 6905 tuner. Don't know yet if it's the ultimate solution, but might be worth a try (see attached image file). The 18800000 setting is a bit arbitrary; I chose it because it is more than 1 Meg and is the "Input Buffer (Bytes)" value x 1000. If the issue persists I may try an even higher value.

If the new value doesn't appear after you change it and click save, refresh the page in your browser, then navigate back to the TV adapters tab.

Thanks to Cody for his help with this!
Attachments
Skip Initial Bytes fix.png
cband
 
Posts: 16
Joined: Sun Aug 24, 2014 4:46 pm


Return to DVB-S2 Quad Tuner PCIe Card TBS6905

Who is online

Users browsing this forum: No registered users and 6 guests