What would cause recordings to have bad timing information?
Added by K Shea about 10 years ago
I'm using TVHeadEnd on a TBS MOI+ - the TVHeadEnd version number is reported as "HTS Tvheadend 3.9.636~g03a69ff"
I have one annoying issue that I can't seem to resolve. I thought I had it fixed and then I made the mistake of connecting a new hard drive to the device (trying to get increased storage capacity for recordings) which turned out to be defective, and somehow it rendered the MOI+ in a state where it would not boot. So I had to do a "factory reset" which meant that I lost all my TVHeadEnd settings and had to start over. Not a big issue, just time consuming, however after the reset the issue I am about to describe shows up a lot more frequently, and I cannot understand why.
This system is used to receive DVB-S2 Free-To-Air satellite TV signals in North America. I should note, in case it is important, that almost none of the channels here send time information as part of their stream, therefore you cannot use the satellite signals to set the time of day. However it is possible to run ntpd as a service to keep the time fairly accurate. Before the crash, doing that seemed to resolve the issue I'm about to describe, but now it doesn't seem to help as much.
The basic problem is this: When I schedule a program for recording, after the recording is finished it may or may not contain bad timing information. The symptom of this is that when I go to play the recording in XBMC, it will display a running time that is inaccurate, sometimes wildly inaccurate. For example, on a half hour program, it may display a time of an hour, or an hour and a half, or in some cases around 25 hours! Or it may in fact display the correct running time, but then the following happens:
On such a recording, if I try to skip forward or backward (to skip a commercial or back up to see something I missed), one of two things will happen. One is that it will take a long time (several seconds) to seek to the desired position, but it will finally get there and stat playing again. The other, far more objectionable behavior is that it will simply stop playing the program altogether, either acting as if I'd pressed the "stop" button or simply returning to the start of the program and starting over. Note that when that happens, there is NO WAY to advance the recording back to where I was previously watching - the ONLY option is to start again from the beginning, and let it run (without attempting to change positions in the program) until it gets to the point where it was before. This is EXTREMELY annoying when it happens.
However, some programs seem to record just fine, and I can't figure out any reason some do and some don't. The bad recordings are not confined to any particular channel or program. The only observation I have made is that this almost never happens to a program recorded within the first hour after a reboot. However, for obvious reasons I don't want to have to reboot the system prior to ever program I want to record.
Before the crash, running ntpd as a service seemed to eliminate the problem, but after the factory reset and re-installation of the current firmware, the problem seems to be back and I would REALLY like to find a solution. I have tried not running ntpd at all (simply rebooting without doing any kind of time correction) and now even that doesn't appear to help, not that it would be a long term solution because without time correction this system loses about 20 seconds per day.
I'd really like to know WHY this happens and what can be done about it. Prior to running TVHeadEnd I was running MediaPortal and never saw this issue with recordings. MediaPortal had plenty of other issues, such as failing to record scheduled programs at all, but it never produced a recording with bad timing information such as this. So what does TVHeadEnd do that might cause this, and is there a way to fix it once and for all?
Replies (3)
RE: What would cause recordings to have bad timing information? - Added by Alex . about 10 years ago
Hi K,
I am not sure if I understand correctly what part of the system or software has bad timing: It is very important to separate timing of the hardware from timing of the software. TVheadend just uses the clock of your system.
My guess would be that your system's clock actually is not correct, can you confirm this ? ( in that case, that is what should be fixed, and it has not so much to do with tvheadend).
On 'regular' computers the battery might be faulty (so the clock gets reset or times not stored).
But I do not know the "TBS-MOI+ "
Can you log in to the system using ssh ? Maybe try to monitor the internal time using a script, and see if that is consistent ( and right, and stays right).
The 20 seconds lag is also not good, you can consider just setting the time using ntp via a cronjob once a day. ( but this should not cause this amount of trouble I would guess, only after some days when time is of by minutes).
Alex.
RE: What would cause recordings to have bad timing information? - Added by K Shea about 10 years ago
I can confirm that the uncorrected clock has a lot of drift, it loses about 20 seconds per day, however I found out how to run ntpd as a background task so that now the system clock stays accurate. I have no way to fix that other than running ntpd, but by running it this way at startup (/usr/sbin/ntpd -p timeserver-address) it does keep the system clock accurate. And yet I still frequently have this issue with recordings, and I do not understand why.
What mystifies me is that if I understand it correctly, TVHeadEnd should just be saving a transport stream (.ts) file to the hard drive, based on what it's receiving off the satellite. I realize that if it's getting a stream with many channels, as it usually would be, it has to do something to break out the desired one, but in that process does it do anything that might change the time information associated with the recording in any way? And if so, is that in some way based on the system clock?
RE: What would cause recordings to have bad timing information? - Added by Graham Agnew almost 10 years ago
I've recently installed tvh into Ubuntu from the unstable PPA and I'm seeing similar skip forward/back issues to those described. I think the version is 3.9.2144. In my case, the TS is coming from a Sat>IP server (GSS.Box DSI 400). I wonder is there something different about satellite transport streams? I switched from stable to unstable to get Sat>IP support, and I'm seeing this issue on satellite recordings.
Prior to switching from stable to unstable, I was able to watch recordings off a cheap DVB-T stick with no problems. Prior to reading this thread, I was thinking this might be an issue with the container so I've switched from Matroska to pass-through, and was going to test again tonight. I've also seen another thread here that links to a blog post about interrupts (for TBS receiver), which might be interesting to the OP, although I didn't think that would relate to me using Sat>IP.
Having read your posts above, I will also re-test recordings off the DVB-T sticks, and check the time on the server while I'm at it.
Cheers,
Gra
=========
Rasperry Pi on OpenELEC 4.2.1
HP Proliant Microserver on Ubuntu trusty
2 x RTL2832U DVB-T USB stick tuners
Grundig GSS.Box DSI 400 Sat>IP server