Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[muzicman0]

My tuners (HDHomeRuns) spit out some corrupted packets when recordings start.  I have read that other tuners can be significantly worse than mine.  It's not a huge problem until I try to transcode the .ts file.  The AV sync will drift (significantly).  I find that if I start the encode 10 seconds in, then 100% of the time, the AV sync is fine (but doing this has other issues with closed caption extraction).

It would be awesome if we could configure a 'Tuner Warm up Time' where it tunes the channel x number of seconds prior to the scheduled recording start.  Then start writing to disk at the scheduled start time.  Of course, it should default to no warm up time.

[astromo]

I've probably missed something.

MC defaults by starting recording 5 minutes prior to the EPG scheduled start time. That works for me. I've never noticed an AV sync issue and no-one else in the house complains. Can't say the same for subtitles but MC's shift function deals with that pretty well, so no issues from me.

[muzicman0]

What I am asking for is different than padding.  I already have 1 minute start and end padding (starting 1 minute prior, and ending 1 minute after scheduled program times).

What I am asking for is for the tuner to start streaming data say 30 seconds before the padded time.  The stream would in essence go nowhere, and would not be written to disk.  It would also only happen prior to the padding time, not after.

I don't have issues if I am simply watching and deleting tv shows.  The problem happens when I compress (for archiving) the recorded .ts file.  If I compress the show to h.264 or h.265 (or really whatever), the AV sync in the compressed file is significantly off by the end of the show.

The resulting file would end up the same length as it is now.

I have seen reports of some lower end tuners taking minutes to start streaming clean data.  Sometimes it is minor like mine, other times, the resulting video is really bad, but ultimately is cleans up after a certain amount of time.

By the way, I am not asking for anything new or innovative, this feature has been implemented in at least one other TV recording software (probably more) for the very reasons I mention above.

[RoderickGI]

Are these HDHomerun Primes, or some other tuners?

Regardless I guess, if the video is taking a while to stabilise, then just increase the pre-padding to two or five minutes, and then transcode from the program start time. That is part of what the pre-padding is for, after all. See if that fixes the problem.

The problem is, as you say, different brands and models of tuners take different times to stabilise, and so if what you are requesting was implemented it would need to be set according to the tuner behaviour, which means it would need to be user-configurable. So MC would have a tuner warm-up time, then a pre-padding time, both of which must be configurable. That would need to be taken into account with tuner clashes, scheduling, etc. That is a lot of complexity in an already complex system.

Just add a bit more pre-padding, and trim it off during transcoding.

[muzicman0]

yes, as I mentioned, they are HDHomeruns.  and yes, I know there are work arounds, however, the problem with 'just start transcoding 10 seconds in' (which by the way, is what I do now), is that I need to rip the closed captions (hard of hearing) using CCExtractor, and then I have to push  the closed captions by 10 seconds ahead, but they are never quite right, because the 10 seconds in on the transcode is never exactly 10 seconds. 

I have 8 HDHomeruns (4 OTA, and 4 primes), and every last one of them do this.  I may be alone in wanting to archive, but I for sure am not alone in this issue since I see it on other forums.

[JimH]

I don't think I've ever seen this problem.  Is it possible that the conversion you do later is causing it?

[RoderickGI]

If the Closed Captions work correctly when you playback the original recording in MC, then I would focus on the transcoding and CCExtractor.

I would definitely increase the pre-padding to get a more stable signal for the actual program. Give the tuner more time.

You haven't said what you use for the transcode, or if you extract CC from the TS file before transcoding, or from the transcoded file after transcoding.

If using MC to transcode, which has issues in terms of the audio produced always being stereo, then I would set the Playback Range for the file before transcoding, so that it only includes the program, and would most likely get the audio and Closed Caption synchronisation correct. Besides, once you have the Closed Captions in SRT Subtitle form, MC can adjust there timing in 100 millisecond steps. So unless the video is stretched or compressed in the timeline by the transcoding function, you should be able to get them aligned correctly and they should stay aligned for the duration of the program.


I'm sorry but I think you have requested a solution that doesn't address the problem. To test that theory, try this simple process.

Pick a program that is going to be recorded, and which will have CC and you will want to archive.
Start playback of the TV channel live five minutes before MC is due to start recording, allowing for the pre-padding.
Process the resulting recording exactly as you do now.

Did that fix the issue? It should have, if your requested solution was going to work, because all you did was manually warm up the tuner and get it stabilised on the channel before starting the recording, just as per your request.

Of course, I'm sure the issue happens to greater and lesser degrees with different programs, so repeat the above test a few times to be sure that it does, in fact, eliminate the problem. One test that works is not the basis of a reasonable conclusion.

[muzicman0]

I don't think I've ever seen this problem.  Is it possible that the conversion you do later is causing it?

Yes, the conversion is what causes it sorta...it's a chicken and the egg scenario.  The AV sync issue is caused when it is transcoded, but it happens because the original file has some corrupted frames at the beginning.  to avoid the issue, simply start the transcoding 10 seconds in (with ffmpeg, "-ss 00:00:10").  Every transcoder is different, and I have used more than 1 to try this. 

I ended up moving on, and while I still use MC for a few things, I moved my TV recording engine back to a linux based solution.

[JimH]

If this is easy to do, we'll do it.

[muzicman0]

I'll keep an eye out.