Recorded TV shows freezing when signal was low on the recording.

[NightWalker86 0]

Hey All,

 

I've got one more issue I've been experiencing with Emby. Details below:

 

Hardware:

 

HDHomeRun Quad tuner with RCA attic mounted antenna and amplifier (works great).

 

 

Emby server:

 

Server 2016 Hyper-V VM (4 vCPU/8GB ram) shared from a Threadripper 1950X Host.

 

Problem:

 

Every now and then the antenna signal will blip for a second if the weather is bad or something. Not a big deal but this shows up as a skipped frame or two with pixel distortion in the raw .TS files which I would obviously expect. When playing the raw .TS file in Media Player Classic or another media player the video will continue on just fine simply dropping that frame (or distorting it really badly depending on the signal loss level) and keep going. However, when this happens, there is about a 50% chance Emby will freeze on this section. When it does freeze, there is another 50% chance that it will eventually recover (usually in about 10 seconds) and keep going. When it doesn't recover though, you have to try and skip over this section completely. There is yet another 50% chance or so that will work and sometimes it just flat out won't and Emby will stay stuck at the section where the signal loss occurred.

 

Steps taken:

 

1. I've played with all the different transcoding options and none seem to make much of a difference at all here. 

2. The problem does not seem to happen when attempting to play the same file from the Emby App on my Android phone

 

Logs:

 

Emby server log and ffmpeg log sent to Luke.

[Carlo 4561]

HDHomeRun Quad tuner with RCA attic mounted antenna and amplifier (works great).

 

Every now and then the antenna signal will blip for a second if the weather is bad or something. Not a big deal but this shows up as a skipped frame or two with pixel distortion in the raw .TS files which I would obviously expect.

 

It's not really working "great" if you have signal issues.

 

Really you should try to get that antenna outside vs in the attic.  You are taking an 8 dB to 15 dB signal hit from it being there vs outside depending on attic materials.  That is a huge amount of signal loss.  Remember 3 dB is a doubling of power. 6 dB is 4 times the power.  So your signal is 5 times lower or more from being inside.  

 

An amplifier does not make your antenna any stronger.  Doesn't work that way.  All the amp does is boost the signal level of what enters it to overcome cable loss and splitters, connectors down stream from the amp.

 

If you absolutely can't move the antenna outside then try to aim it better for your problem station.  May or may not be doable depending on how many towers you pickup and their orientation.

 

Beyond fixing the actual source of the problem the only alternative is to reprocess any problem files through a 3rd party program/script that can fix the timing and frames in your files.  ffmpeg and handbrake can both do this but you take a hit in quality any time you reprocess the video so this isn't ideal and it does take time to do.  It's far better to try and fix the problem ONE TIME then deal with fixing it ALL THE TIME.

[NightWalker86 0]

It's not really working "great" if you have signal issues.

 

Really you should try to get that antenna outside vs in the attic.  You are taking an 8 dB to 15 dB signal hit from it being there vs outside depending on attic materials.  That is a huge amount of signal loss.  Remember 3 dB is a doubling of power. 6 dB is 4 times the power.  So your signal is 5 times lower or more from being inside.  

 

An amplifier does not make your antenna any stronger.  Doesn't work that way.  All the amp does is boost the signal level of what enters it to overcome cable loss and splitters, connectors down stream from the amp.

 

If you absolutely can't move the antenna outside then try to aim it better for your problem station.  May or may not be doable depending on how many towers you pickup and their orientation.

 

Beyond fixing the actual source of the problem the only alternative is to reprocess any problem files through a 3rd party program/script that can fix the timing and frames in your files.  ffmpeg and handbrake can both do this but you take a hit in quality any time you reprocess the video so this isn't ideal and it does take time to do.  It's far better to try and fix the problem ONE TIME then deal with fixing it ALL THE TIME.

 

Actually it does work great, and I understand the basic concepts of antennas and amplifiers. There will be times where, for whatever reason, the signal is interrupted (weather, interference, etc.). The signal on the channel in question is usually just fine, but every now and then it will blip out for just a second. It happens. I do not want to externally mount this antenna for a multitude of reasons, first being that it isn't really necessary where I live. I get where you are coming from with the whole signal/antenna placement thing and we can have a big discussion about that but I think you are missing the main point... playback.

 

The recorded .TS files from the antenna/tuner playback just fine when viewed in a media player such as MPC. Sure they skip over that 1 second in a file that has signal loss, but that is exactly what it should do. The problem comes when Emby attempts to playback those same files. It is freezing up on those files rather than just moving on. To your point, it would be in everyone's best interest for Emby to properly handle these files as signal loss will happen from time to time. It shouldn't stop the file from being able to continue to play only within Emby itself. It is also strange that this doesn't happen on the same file within the Emby app on Android devices (and I assume other apps).

 

Any ideas?

[ebr 16195]

...only within Emby itself. It is also strange that this doesn't happen on the same file within the Emby app on Android devices (and I assume other apps).

 

Sorry if I missed it but, from what app are you having this problem..?

[NightWalker86 0]

Just logged into the HDHomeRun and ran a test on the channel in question that a lot of my recordings come from. Here's the stats on the signal while streaming from it directly from the tuner:

 

 

Tuner 0 Status

Virtual Channel none Frequency 509.000 MHz Program Number 3   Modulation Lock 8vsb Signal Strength 89% Signal Quality 100% Symbol Quality 100%   Streaming Rate 16.497 Mbps

 

Looks like it was varying from around 86 to 90% signal strength over the course of a few minutes.

[NightWalker86 0]

Sorry if I missed it but, from what app are you having this problem..?

 

Hi ebr,

 

I primarily stream locally through Chrome or Firefox from an HTPC in the living room by going directly to Emby on my LAN (Version 3.5.3.0). I've been troubleshooting this problem on and off over the past month or so and during the course of some of those steps I noticed that streaming the exact same file from the Emby App on my phone (app version 3.0.16) doesn't result in this problem. It simply skips right over the problem section and keeps on going.

 

Also, perhaps I've jumped to conclusions about this being a "signal issue" causing the dropped frames. I don't have any proof of that since I haven't tried to log the signal strength over the course of an evening or something. I can simply tell you it looks exactly like what you would expect when the signal drops down for a split second. Judging by the signal numbers posted above though, you can see normally my signal strength is pretty good on this channel.

 

Regardless, my primary concern is the playback problem and what Emby appears to be doing when it encounters corruption/dropped frame/etc. Thanks for the help guys!

[Carlo 4561]

Signal strength is mostly meaningless due to your amp.  You need to look at Signal Quality and Symbol Quality.

You want your Signal Quality to be at 70% or better and Symbol Quality to stay locked at 100%.  If this doesn't happen you will have issues for sure a lot more frequent.  You can tolerate lower Signal Quality of course but then you will get interference with different weather and atmospheric conditions.

 

With that said both of those look great (100%) so you really shouldn't have any ongoing issue except the occasional glitch that happens (cable too). And it seems your attic setup is getting excellent signal quality so you are good there.

 

Any device/player that plays direct will usually not have an issue when this happens as they tolerate this better.  Anything running through ffmpeg to remux/transcode can have temporary sync issues that may or may not be recoverable.  I've had this happen at the beginning of a 3.5 hour NFL football game and it sucks!

 

I can open VLC and play the file back while it's being recorded.  I can use a different player such as Emby Mobile and it will direct play the file and I get no issues.  However, using Android TV or Roku will involve the ffmpeg process and cause the error.

 

If watching Live TV just stop and restart will fix it.  If this is a recording you may have to wait until the recording is finished then run it through a ffmpeg or handbrake process to fix it. I have a post process set of scripts that cuts commercial and converts all my recordings to either MP4/H.264 or MKV/H.265 (depends on source content) so I typically don't see these issues unless I'm trying to watch it while it's still being recorded.

 

Not what I personally use but MCEBuddy will cut commercials and reprocess your files for you and this will fix 99+% of these issues.  The only other thing you can try to do is use Emby players that can direct play the content vs direct stream or transcode.

 

Don't know how much help that is but that's my experience anyway. 

[Carlo 4561]

Doubt this is related but just thought I'd throw this out.  If you have a single NIC in your Emby server and are recording while transferring files or saturating your NIC you could drop frames from the HDHomeRun.  

[NightWalker86 0]

Cayars,

 

Good info! We are almost never watching live TV and recording at the same time so that shouldn't be an issue. The VM the Emby server runs off of has a vNIC associated with it from the Host server but that NIC is far from saturated (especially during playback). I tested this last night by looking at the traffic graphs on the guest and host machines for the NIC in question and it was barely breaking a sweat. Last night I tested playback from my PS4 over a straight Emby DLNA media server connection to the recording. Played just fine and skipped right over the frame that has been causing the issue.

 

As far as I can tell from multiple tests, this issue is isolated to playback from Emby within a browser on the LAN. Every other test from multiple different devices/methods/apps seems to playback just fine. To recap:

 

Tested working:

 

1. Playback from Android device on the 3.0.16 Emby app.

2. Playback on PS4 over a DLNA media share from Emby directly.

3. Playback from the Emby app on my Samsung TV (forgot to grab the App version of that).

4. Playback of the .TS file directly using Media Player Classic.

 

Tested not working:

 

1. Playback of the recording from within the Emby web page on the LAN in Firefox/Chrome/I.E. 11

2. Tested #1 on 3 different computers (Windows 10 & Server 2016) with varying hardware specs including the Host directly (TR 1950X/64GB RAM).

 

I primarily watch media in the living room on my HTPC which means I am browsing directly to the local Emby web page and playing from within there. Thus I experience this problem with any file that blips for a second. It is quite frustrating. I have read a bit regarding ComSkip and would like to implement that but it appears to be quite the animal and I haven't had the time necessary to dedicate to that. In the meantime though, this definitely does appear to be a repeatable and verifiable issue that should be looked at.

 

Any suggestions? Thanks for the help guys!

[Carlo 4561]

I think you would probably also have the same error if you used Android TV or a Roku as both of them would need to repackage the file and would not direct play it.  That seems to be the "key" in this is if the file goes through ffmpeg or not.

 

If running windows, download a copy of MCEBuddy.  Then copy the comskip.exe from the Emby system directory and overwrite the version contained in the MCEBuddy install.  This will handle the commercial cutting and conversion if wanted and simplifies the whole process.  With the conversion it will fix this "blip" issue as well.

[NightWalker86 0]

I think you would probably also have the same error if you used Android TV or a Roku as both of them would need to repackage the file and would not direct play it.  That seems to be the "key" in this is if the file goes through ffmpeg or not.

 

If running windows, download a copy of MCEBuddy.  Then copy the comskip.exe from the Emby system directory and overwrite the version contained in the MCEBuddy install.  This will handle the commercial cutting and conversion if wanted and simplifies the whole process.  With the conversion it will fix this "blip" issue as well.

 

Wouldn't playing the file over the Android app on my phone from an external network (T-Mobile) need to repackage the file as well? Playing over the phone doesn't present this problem.

 

PS: I'll look into the ComSkip setup at some point soon since I do want that feature anyway. Thanks.

Edited October 11, 2018 by NightWalker86