Bug #3004
Bad recording times and can't skip forward or backward in recording made with late model TBS DVB-S2 cards
0%
Description
I have recently added a TBS6905 DVB-S2 card to a system that previously had a TBS6985. With the new card, recordings made by TVHeadEnd often show times much longer than the actual time of the program, for example 8 or 9 hours for an actual one hour program. This in itself would not be a big deal except that when this happens, it is impossible to do forward or backward skips in the program, at least when using Kodi. If you attempt to skip or move around in the program, either you get thrown back to the start with no way to advance forward, or it just sits there and hesitates for quite some time but essentially doesn't appear to do anything. This was not a problem with the TBS6985 although in the back of my mind I'm thinking you had to do something to fix that problem with the older TBS cards at one point. I am not sure what the TBS6905 does differently, but there is definitely something wrong.
I am currently running TVHeadEnd Build: 3.9.2514~g50016a1~wheezy
If I use ffmpeg on the "bad" recording, using the copy option (for video, audio, and data) and output it as another .ts file, I can play the "converted" file with no problem. Which is strange because I am essentially telling ffmpeg to copy the file as is, and not change anything. But the simple act of doing that seems to fix the bad timing information in the recording.
History
Updated by Jaroslav Kysela over 9 years ago
Updated by - Status changed from New to Invalid
This version is unsupported. There was an error related to the matroska muxer which caused that the seek table was not saved sometimes to the output file.
Updated by K Shea over 9 years ago
Updated by I am confused by this. The latest version offered for upgrade is version 3.9.2827~g477feab~wheezy. There is nothing offered in the 4.0 or 4.1 version. The repository I am using in my /etc/apt/sources.list is:
deb http://apt.tvheadend.org/unstable wheezy main
Is there a different repository I should be using under Debian to get me a more recent version? Also, I don't understand why the 3.9 branch would work fine and never produce these errors on any signal coming from the TBS6985 card, and why only inputs from the newer card would be affected.
(Please don't say I should build from source. I am not very proficient with Linux and every time I have ever tried to build anything from source, it's been a roaring disaster and in a couple cases I completely hosed the system. I can handle using apt-get to get a new version of software from the repositories and I can handle adding or changing a repository in /etc/apt/sources.list but I'm afraid that's about my limit. Also, your page at https://tvheadend.org/projects/tvheadend/wiki/AptRepository says "There are no 4.x official stable builds for Wheezy or Jessie but packages for 3.4 are available (see below).
However the above builds for Ubuntu are known to work on Jessie." If there really is a problem with the matroska muxer and you have fixed it in 4.0/4.1, would you please consider making the fix in the 3.9 branch so that Debian Wheezy users will have it?)
Updated by K Shea over 9 years ago
By the way, I'm not sure if this matters, but we are saving the recordings as .ts (transport stream) files, so I'm not even certain that the matroska muxer is involved in this. The files are not .mkv or anything like that.
Updated by Jaroslav Kysela over 9 years ago
Then it's kodi issue. The .ts files (using the pass-through muxer) contains data received from the DVB input without any modification in tvh..
Updated by Rob vh over 9 years ago
Updated by I have had similar problems with 3.9 snapshots from 3-4 months ago. They seem to have gotten fixed about 1 month ago. I only occurred on oscam streams from CanalDigital, never on FTA. In my case, the starting time of the recording would appear to be 13:00 hours with ending time 1:15 hourrs, and yes, Kodi doesn't like jumping to a fixed time. I does support relative jump, i.e., 500 followed by a right arrow. In some cases, the recording would be viewable with vlc, in other cases, vlc also couldn't.
Could this have anything to do with starting the .ts too early, i.e., is there a synchronization signal in the stream and tvh should wait with recording until the sync has been received?
Updated by K Shea over 9 years ago
I very much doubt it is a Kodi issue, but I think Rob may be onto something. If you chop off say the first 1 MB (arbitrary amount to get rid of a small bit of the start of the stream; it may be that some lesser amount of data could be discarded) from the start of a "bad" .ts file then it plays fine in Kodi, and there is no problem with bad times or skips.
In one of the other online forums someone, suggested that it might be that TVheadEnd saves the data faster than the TBS driver starts sending data to the data buffers. I have no idea how to determine if that's actually the case.
Updated by Sean Micklem over 9 years ago
Updated by Found the solution here (and it IS a setting in TVHeadEnd): http://www.tbsdtv.com/forum/viewtopic.php?f=168&t=9484&sid=29b42da94354043dc4b9a525775f30f5
I had first tried upgrading to the latest 3.9 version (currently running HTS Tvheadend 3.9.2827~g477feab~wheezy) and that did not help, but the fix described in the above thread did.
Updated by B C over 9 years ago
Updated by well it is a buggy tbs driver. btw, 3.9 is no longer in development