Jump to content

Emby DVR Prematurely Terminating Recording


martincom

Recommended Posts

martincom

We're experiencing trouble with Emby prematurely terminating recording.  It appears the issue is likely with the stream.  With one recording, the picture would still frame for a second or so two or three times and the audio became way out of sync with the video.  These are OTA recordings and I'm knew to doing so.  I believe we have very good signal strength at the tuner, as we seldom ever note any issues when viewing live, whether through the HDHomerun/Emby or the actual TV tuner.

All the channels we can receive are not the primary broadcast transmitter, but translators.  I'm suspecting the issue maybe with the signal feeding the translator transmitter.

1. Will the "Default Recording, Stop When Possible" setting impact the amount of time Emby continues to record when there is a loss of signal?  If so, will the timer reset and not cease recording when the timer value times out, if the stream is restored?

2. Below are HDHomerun tuner signal quality screen shots from the two channels we experienced premature termination of recordings.  Is their someone with experience who can offer an opinion of the signal quality and a rating on a scale of 1 to 10 as to the quality of "fade margin" before Emby ceases to detect and terminates recording?  The 12.1 channel is a 1080i broadcast and the 26.1 channel is 720p.  I've checked these signal levels periodically over a two week period and they are consistent.

432958596_HDHomerun12.1signalstrength.JPG.d03cb23ff5079853757f5186096eab3c.JPG

 

461207396_HDHomerun26.1signalstrength.JPG.4e1f9640c4bb6facee1dcc6e2af7b820.JPG

Link to comment
Share on other sites

Hi there, can we please look at an example? Please attach the information requested in how to report a problem:

The recording should try to reconnect and try again in the event of loss of signal.

Thanks !

Link to comment
Share on other sites

martincom

The recordings in question were made early in the week before I migrated from stable to the beta release of Emby, again.   So the logs from the time period of those recordings were made were lost in the migration.

With the new network seasons starting, the number of recordings we are making are increasing.  When it occurs again, I'll post the relevant logs.

Link to comment
Share on other sites

That would be great, thanks.

The fact that it stops is normal, but it should recover as long as signal is regained. So that's what I'll be looking for.

Link to comment
Share on other sites

Just a comment on that signal quality being shown.  At 76% you have a quality that is going to be borderline at times if it bounces around at all. You really want this to be 100%.
If you see the issue of recordings stopping early check the quality of that channel and see what it says.

If you have the antenna coming in and have any splitters or other things inline try removing them to see if this improves.

I'm not saying this is the source of the problem but wanted to point out that 76% is not ideal.

Link to comment
Share on other sites

martincom

Cayars, thank you for the reply.  Help me understand these fields.  I was speculating that signal strength what was the strength of the RF carrier and signal quality the bit error rate.  I don't have even a good guess for symbol quality.  Was I close with the first two?

Link to comment
Share on other sites

Check out this simple explanation:
https://info.hdhomerun.com/info/troubleshooting:signal_strength_quality

There are three percentages reported by the HDHomeRun -

Signal Strength (ss)

raw power level as measured by the receiver

Signal Quality (snq)

how clearly defined the digital data is

Symbol Quality (seq)

Amount of correct or corrected data over the last second

The above definitions can be confusing, so a much simpler definition is to imagine listening to the radio:

Signal Strength represents the volume
Signal Quality represents how clearly you can hear the lyrics
Symbol Quality indicates the percentage of the lyrics you could hear or guess correctly

As it turns out, Signal Strength is somewhat irrelevant; if your antenna isn't pointed properly, it doesn't matter how loud you turn up the volume, the static will prevent you from hearing the lyrics correctly. Similarly, amplifying a weak HDTV signal can result in a high signal strength but too much noise to decode the digital data correctly.

Use the Signal Strength for a rough idea of direction, but align the antenna for the highest Signal Quality, ignoring Signal Strength. When aimed correctly, Symbol Quality will show 100%, indicating no errors in the output. Splitters and amplifiers can introduce noise which will lower the Signal Quality, even if the Signal Strength increases.

Link to comment
Share on other sites

martincom

Thanks for the link!  My speculation as to their meaning was very close.

Signal strength would be the RF carrier.

Signal quality would likely be how well the demodulated data is defined, voltage level, slope, etc

Symbol quality would likely be bit error.

I erected my antenna on the side of a 64' self supporting tower.  I utilized an omnidirectional antenna as the two primary broadcast towers were near 180 degrees apart and the third was near 90 degrees between.

1445116673_TVstationsmap.JPG.557d9a67b81e30d0f4096201d5af6b7e.JPG

A directional antenna would have yielded a stronger signal.  However, it would have required a rotor or the non-aligned stations would have much weaker signals that would also have multipath issues.  In the old days of NTSC, multipath would have resulted in picture ghosting as the analog signal was AM modulated.  Today, with ATSC, multipath would likely impact the "Signal Quality" measurement.  Still, it is much forgiving than NTSC.

When I erected the antenna, I actually setup a small TV that had a signal strength meter screen at the base of the tower.  In this manner, I could test the signal strength at various elevations.  The transmitter of primary  concern, channel 26.1, was only 10 miles away, but only a 100 watt.  Also, at its operating frequency of 509MHz, multipath would likely be an issue.

DSCN1620.thumb.JPG.8373664ac066371b3a4dd6013e223a85.JPG

The signal strength bar graph of the television likely corresponds to the "Signal Quality" of the HDHomerun.  It indicated a stronger signal on channel 26.1 than 12.1, as depicted in the above HDHomerun tuner status screen shots.

I clamped the antenna to tower members with quick release clamps and used binoculars at the higher elevations so I could see the TV signal strength screen.  The best signal strength was not at the top of the tower, 64', but actually quite a bit lower, at 24', for channel 26.1.  Once I found the approximate strong signal elevation, I moved the antenna up down on the tower to determine where the signal began to decline and then mounted the antenna in the center of that band.

DSCN1618.thumb.JPG.83b56c6a51ab61fcb9d4379c8f55c0da.JPG

 

I'm speculating the round disc portion of the antenna is the UHF section and the vertical element is VHF.  In the past, all television antenna were horizontally polarized (elements being horizontal).  If I am indeed correct that the vertical element is VHF, this would be a vertical polarization.   This could also be a factor in why I'm only achieving a 76% "Signal Quality", on channel 12.1, when I have 100% signal strength, again likely due to multipath.

Back in the day, when FM broadcast radio was first coming to be, the broadcast transmitter antennas were all horizontally polarized, as FM radio was just in the home.  Once FM radio began to be installed in autos in a greater number, the broadcasters began changing their transmitter antenna to circular polarization, as auto antennas are, obviously, vertically polarized.

The disc portion of the antenna would be horizontally polarized.  I'm going to further speculate that is why I'm achieving a 88% signal quality with only an 88% signal strength on channel 26.1

There was a similar model of antenna that had the same UHF disc, but had a horizontal dipole for VHF.  This would have likely improved the Signal Quality on channel 12.1.  However, being a horizontally polarized antenna, it would have been directional.  The UHF channel signal;s would have also been received through it, especially with the lowered numbered (frequency) channels.  This would have likely created multipath issues with them, which would have degraded the signal quality.  As such, why I went with the model that had the vertical, omnidirectional, VHF element.

I did have a significantly higher signal strength on the other channels when I had the antenna at a higher elevation, on the tower.  However, the channel 26.1 signal strength was quite a bit less.  The signals from the two 180 degree apart transmitters are now near equal.  Of course, the tower at 90 degrees between the two is at 100% for all measurement categories, as it is only 5 miles away, on a high elevation hill, 500+ foot tower, and a 10kw transmitter.  It's always a compromise when choosing an antenna for multiple transmitter locations/frequency bands.

Elevation and antenna do make a difference.  When I erected the tower 20+ years ago, I installed a UHF antenna on a sidearm to receive a translator that was co-located on the tower at the 90 degree point.  It operated on channel 54, which is quite a bit higher in frequency.  Star Trek Next Generation was not carried by the networks, but syndicated.  The channel 54 translator was an independent who carried the program.  So the antenna I chose was a high gain directional cut with an emphasis for the higher UHF channels.  When we cut the cord with DirecTV, I climbed the tower and swung the antenna around to the direction of the channel 26.1 transmitter.   We rarely ever had enough signal on channel 26.1 for a TV tuner to detect it.  The co-located channel 16 transmitter was usually a solid signal, but it had a larger antenna (the top 33' of the tower was the antenna) and a 1kw transmitter.  The channel 22 tower is at the antenna's side.  Though it was less than 5 miles away, the picture was always pixelated.  Surprisingly, the channel 12 signal was almost always watchable with minor pixelation, off the back side of that antenna.

The antenna directly above it, on the sidearm, is for FM broadcast.  The dipole below is a FM omni.  The top mounted antenna is for two-way radio.

Climbing that tower was a stark reminder that I am no longer the man I once was.  It wiped me out.  I am in my mid-60s and dragging along some extra ballast above the waist line.

DSCN1613.thumb.JPG.d8d69c7458687096a28a3b3b056bdd01.JPG

 

When I erected the tower 20+ years ago, I also installed the antenna distribution system.  This was back in the days of NTSC, so picturing ghosting could easily become an issue in the distribution system.  So the bulk of the distribution system utilizes line drop taps, rather than splitters.  Of course, the insertion loss from the trunk line to the set is quite a bit higher.  Thus, I have a 33db gain amplifier.  This is overkill for ATSC, but it was in place, paid for, and works well.

In the photo below, the far left, white, coax cables was the DirecTV distribution system.  I still utilized a portion of this as a means to extend my LAN, over coax, to televisions.  It is limited to 100mbs, but is better than wifi and keeps the bandwidth load off the wifi.

The center black coaxes are the distribution system for the OTA TV antenna.  The right group of black coaxes are the distribution system for the FM broadcast antenna.

 

DSCN1632.thumb.JPG.123808d709e2ba1365166c71d1922ad7.JPG

 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
martincom

My issue has yet to re-occur.  I'm going to speculate the problem was insufficient processing ability.  I run Emby on a server dedicated to media, under Server 2012.  Servers do not, typically, require a lot of processing power.  As such, I only equipped the server with a two core processor.  This worked fine until I began to utilize the live TV features of Emby. My first issue with lack of processing power was the transcoding of interlaced resolutions to progessive.  It would bump against the 100% capacity of processing power.

I'm going to speculate this was my issue again while recording.  While transcoding does not occur during recording, but rather playback, this particular issue had two programs being recorded simultaneously.  So I'm going to further speculate the processing capacity was being overrun.

I found a compatible processor upgrade on Ebay for $8.00, faster, 4 cores, and 8 threads.  Also, contrary to Microsoft's published specs, I didn't have to upgrade and add licenses to the OS to utilize the additional cores/threads.  Now, when transcoding, it utilizes less than 20% of the processing capacity when transcoding 1080i to 1080p.  I also have not had a truncated recording since upgrading.

Link to comment
Share on other sites

BillOatman
On 9/25/2021 at 12:55 PM, martincom said:

DSCN1632.thumb.JPG.123808d709e2ba1365166c71d1922ad7.JPG

Holy crap man, how many people are you supplying TV to? :)  You would probably laugh at my setup :) 

 

Link to comment
Share on other sites

martincom

Well, I spoke to soon.  A couple of recordings made over the weekend were truncated.  The log file for this time period was also truncated before the recordings occurred.  So there is no log data for the period when the truncated recordings occurred.

I believe I found the issue.  I have my server array partitioned as two virtual drives.  The OS and Emby are installed on a 115GB virtual drive.  The media files are stored on a 16.2TB virtual drive.  The virtual drive for the OS/Emby was full due to temporary transcoding files, in the default directory path.

I deleted the temp transcoding files and it appears to be recording normally again.  At least the recording we had scheduled for yesterday evening recorded fully.

I believe the solution here is to eliminate the unnecessary transcoding (interlaced to progressive), as discussed in other threads,  and incorporate a routine to "clean up" temporary transcoding files.

My temporary remedy will be to change the default path for temporary transcoding files to the larger virtual drive.  If the transcoding remedy is protracted, I may have to add a batch file to periodically delete the temporary transcoding files, as another member has done.

Link to comment
Share on other sites

Hi, do you have to use virtual drives or can you point things to physical drives?

If you re having trouble with transcoding files staying around longer than needed use a script to kill any files in that folder older than say 6 hours then just set it up to run 4 times a day via your OS's scheduler. (this problem seems to be fixed in the current beta)

Link to comment
Share on other sites

martincom

Hi, we're probably having a terminology issue.  It is a RAID50 array of 8 physical drives.  If it was a single hard drive, I would then utilize the terminology of "drive partition".   However, in this RAID configuration, it would not be an actual drive partition.  The drive controller manual refers each multiple drive "partition" as a "virtual drive".  My path definition is exactly the same as a physical drive.

I migrated back to beta on 9/22/21 and that was a "remove all traces" install (and I manually removed the traces it did not).  I believe that install was beta 4.7.0.11.   On 9/30/21, I updated to 4.7.0.13 and that remains in place at this time.  Which version was the "fix", to delete temp transcoding files, initiated?  The files I deleted may have been created under beta 4.7.0.11, but anything before that would have been deleted with the move from stable to beta on 9/22/21.

I just tested it, with a live program transcoding 1080i to 1080p, and it did delete the transcoded files immediately upon exiting the program.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...