Emby not releasing tuner while transcoding after recording?

[montec07e 9]

I've noticed this a couple of times now and thought I would bring it up: I have a QNAP TS-451+ with Emby (Version 3.2.40.0 -- not the new beta yet) set up to convert Live TV recordings to a streaming friendly format (MKV). The recording will take place, all fine and good, but then Emby will hold the tuner as active after the recording is done while it converts/transcodes the recording (I'm assuming .TS file) into the x264 .MKV. Most times this isn't an issue, but if it has just finished recording a 2-hour show, it may take an hour or two (or more if there are other recordings getting converted at the same time) to convert the recording. During that time the tuner is still locked and not available for other recordings.

<br><br>

I have at one point, when I knew all the scheduled recordings were past the times they should have stopped and the tuners (HDHomerun Connect.FREE (dual tuner)) were still active and unavailable, unplugged the power from the HDHomerun and plugged it back in. The tuner status under that admin Extras/Live TV showed them now both to be available again, and the recordings that were active (being converted) were still being converted, so Emby didn't need the tuner anymore, but wasn't releasing them.

<br><br>

TL;DR: Set up recording of Live TV for a show that airs 5:00-7:00. At 7:00 Emby starts converting the TS file it just created of the show, but keeps the tuner active/locked/"watching" for hours (when it no longer needs it) while it converts instead of releasing it for other recordings.

 

 

(PS. First time posting -- please be gentle. lol)

Edited December 4, 2017 by montec07e

[Luke 42077]

Hi there, we're sorry to hear about this. Please attach the information requested in how to report a problem.

 

My prediction though is that you need to disable the realtime recording conversion feature because it might not be happening quickly enough for your system. In other words, if the conversion is happening slower than the broadcast, then as things currently stand the tuner will remain open until the conversion finishes.

[montec07e 9]

No need to be sorry -- The program, even with this small hitch (if it even is one) is really amazing! (and talk about a speedy reply -- Luke, you're amazing, too!)

 

Here's an example, actually a smaller one: Simpsons episode, 30 minutes, was supposed to record from 8:00-8:30pm. It's now 9:02pm as I'm typing this, and it's still listed as an "Active Recording" and the tuner it was using is still being "watched". (log attached (I think, haha, bear with me...)).

 

I hadn't thought of it, but yeah, it there's a setting or something I've missed that would allow it to transcode in real-time, please, I mean PLEASE point me in the right direction! :-) I just assumed I would need to let it cook after the recording finished and it worked its way thru converting it. (Also VERY MUCH looking forward to the new .NET version hopefully releasing.. well, when you guys think it's ready!)

 

I should say, too:  the attached transcode log is one of 3 recordings being transcoded at the moment -- all 3 recordings' end times were no later than 8:30, and I don't doubt my QNAP's Celeron is "stressed" at the moment.  ;-)

Sample_Log_1.txt

Edited December 4, 2017 by montec07e

[OddbOd 21]

@@Luke The log shows that Yadif is being forced to run with no CPU optimizations ("yadif=1:-1:0"), which can't be helping the things. Setting it to auto ("yadif=1:-1:-1") should yield some improvement.

[montec07e 9]

A quick follow up:  I really had no intentions of watching any of the streams as they record, so on-the-fly transcoding wasn't really necessary for me.  I selected the option to "Automatically convert recordings to a streaming friendly format" because I actually would like to covert them -- just didn't realize and didn't need it to be in real-time.  Not entirely convinced that without hardware acceleration the little Celeron would be able to keep up, let alone with multiple streams, I've unchecked the option and now transcode the recordings on another computer with an i7 and Handbrake, then replace them back on the QNAP.  Not a problem any more. Although, the point/question originally was what actually triggers the tuner to be released -- the end of the recording time or the end of the transcoding (it appears to be end of the transcoding with the tuner held active until it's done).  I was hoping in my exaggerated case (with the transcoding not keeping up and lasting up to hours after the end of the recording time), that it might expose a possible small improvement that normally wouldn't come to light under normal circumstances.

[Luke 42077]

Thanks for the feedback !

[Luke 42077]

@@Luke The log shows that Yadif is being forced to run with no CPU optimizations ("yadif=1:-1:0"), which can't be helping the things. Setting it to auto ("yadif=1:-1:-1") should yield some improvement.

 

@@OddbOd, I suppose i can look this up, but what difference does this create? thanks.

[OddbOd 21]

It automatically enables SSE optimizations if they're available, the 0 setting disables them.
 
Yadif (or any other spatio-temporal/motion compensated deinterlacer) is an obvious bottleneck that partly explains why x264 is running so slowly with this recording, 0.2 fps is pretty slow even for a 2GHz Celeron.
 
While it's tempting to simply avoid the problem altogether by encoding to H.264 interlaced, this can cause problems when automatically re-encoding interlaced broadcast recordings because the field order flagging can't be trusted. I've previously recorded TV broadcasts that were flagged as Top Field First only to find that, after one of the commercial breaks, the order had changed to Bottom Field First or even Progressive. I now do what montec07e is doing and either perform any re-encoding on my more powerful desktop or just keep the original Transport Stream.

@@montec07e As a workaround you could try Emby's Recording Post Processing feature to automate conversion and ensure your HDHR tuner gets released. There is a build of HandBrake_CLI on QNAPClub's unofficial App Store which works fine (no HW transcoding though). I have not tried it for this explicit purpose myself so YMMV.

Edited December 30, 2017 by OddbOd

[montec07e 9]

To be fair and completely in context, the trancoding log I attached was 1 of  4 streams transcoding at the time, and at least one was a HD PBS show that took more than a few hours to finally finish.  Not that some optimizations wouldn't/couldn't have helped (of course they would!), but it would explain the 0.2 fps a bit better.

[OddbOd 21]

Even so, your original point still stands. The tuner should be released at the end of recording not the end of encoding.

[Luke 42077]

Thanks for the info.