Jump to content

Pixelation and Glitching in Recorded TV using Emby DVR


EmbyKiwi
Go to solution Solved by EmbyKiwi,

Recommended Posts

EmbyKiwi

I have been using the Emby DVR for a few months and have been pretty happy with the results recording and watching general TV programs. Recently the Rugby World Cup started showing on TV here in New Zealand and these recordings are significantly longer than the usual programs I had been recording. Watching the first game for NZ in the competition (on my Android Smart TV client) it played fine until about 40 minutes into the game (about 1:40 into the recording) when it started pixelating and glitching for 5-10 seconds. It then came right for a few minutes and then glitched again and repeated randomly throughout the rest of the game. I wasn't sure whether the glitching was in the play-back or the recording so, the following day, I opened the recorded file in VLC  and tried playing it. It glitched again in the same places suggesting to me that the issue seemed to be in the recording.

 

I had previously been using Mediaportal for recording TV and, as I had two HD Homeruns, I had allocated one to Mediaportal and one to Emby while I was testing Emby out. For the second game a week later, I recorded the game on both Emby and Mediaportal. Again, part way through the recording the Emby recording started glitching. I swapped over to Mediaportal and it had recorded the game absolutely fine, from the same signal source. Again, I subsequently checked and the issue was in the recording, not just the playback.

 

For a recent game, I swapped the HD Homeruns over between Emby and Mediaportal to see if the problem followed the HD Homerun or the server. Again, Emby glitched and Mediaportal played/recorded it fine, suggesting that the issue was on the Emby side rather than the signal side.

 

My Emby server is a 12 month old Core i5 with 8GB RAM and two SSDs, one for the OS and one for Recording, running Windows 10 Home. It is connected to a Gigabit LAN, along with the HD Homeruns (and the lower spec'ed Mediaportal server). It is running Emby version 4.2.1.0 with no other 'server' processes running on it.

 

I have attached logs for the most recent recording which are rather large but the instructions for posting did say not to strip them out so.... :-)

 

The program being recorded started at 7:00pm on Sat 26th Oct 2019 with a 3 minute pre-buffer so 6:57pm approx start time. I started watching around 8:40pm and fast forwarded through bits of the pre-game show until I got close to kick-off when I started getting pixelation again. Just before 9:00pm (kick-off) I stopped watching on Emby and swapped across to Mediaportal and watched the game there with no issues. 

 

I have also included 2 screenshots taken off the Emby recording a few minutes apart showing the sort of pixelation I am talking about. They are being played in Emby Theatre in a different PC a few days later and show the timestamp in the recording where some of the issues occur. VLC also glitches in the same places.

 

I have recently noticed some pixelation on other longer shows (over 1 hour) but not as badly. Shorter shows seem to be OK???

 

I have really been enjoying my Emby experience and being able to watch all our media from the Smart TV with the one remote has been a big plus on the WAF side so it would be great if someone could help me sort out this last little glitch! :-)

 

Many thanks in advance.

 

PS. NZ Free to Air TV is H.264 encoded. The HD Homeruns are 'HDHomerun Dual's Model : HDHR3-DT.

 

 

 

embyserver-63707731197.txt

ffmpeg-remux-6d613bba-6221-493a-ab71-8894d0aafacf_1.txt

ffmpeg-remux-1793ff98-0ed1-44d7-baf8-965328f3b33a_1.txt

post-531652-0-73651600-1572302615_thumb.jpg

post-531652-0-90660600-1572302622_thumb.jpg

Link to comment
Share on other sites

somedude

If it happens on multiple players, that's definitely corruption on the recorded file.

Interesting it was able to be compared across 2 tuners and servers and still happened like that.

 

I'd say you're looking at a possibly bad hard drive (yes, even SSDs get weird) or there is something in Emby that didn't record it correctly.

 

 

Link to comment
Share on other sites

If it happens on multiple players, that's definitely corruption on the recorded file.

Interesting it was able to be compared across 2 tuners and servers and still happened like that.

 

I'd say you're looking at a possibly bad hard drive (yes, even SSDs get weird) or there is something in Emby that didn't record it correctly.

 

More likely it was actual signal corruption at the time of recording.

  • Like 1
Link to comment
Share on other sites

SHSPVR

More likely it was actual signal corruption at the time of recording.

 

Yup that happen but Emby sure doesn't like one bit 

Link to comment
Share on other sites

EmbyKiwi

More likely it was actual signal corruption at the time of recording.

 

The two HDHomeruns are connected to the same signal splitter so presumably both Emby and Mediaportal were getting basically the same signal. If there was 'signal corruption' coming through then I would have thought I would have seen the same thing on both recordings? Swapping the Homeruns over was an attempt to see if the signal to one Homerun was weaker than the other but no change.  

 

Is it likely that Emby handles 'signal corruption' differently from Mediaportal when recording? I had thought that with H.264 streams the 'recording' was basically just reading the data off the tuner and dumping it straight to disk in an appropriate container. I didn't think that the server was required to do much interpreting the data or error-correction along the way, unlike the good old days of analogue TV signals! :-)

Link to comment
Share on other sites

EmbyKiwi

Yup that happen but Emby sure doesn't like one bit 

 

@@SHSPVR Have you found Emby more pedantic than other systems with corruptions? Is this in the recording or the playback? 

Link to comment
Share on other sites

SHSPVR

@@SHSPVR Have you found Emby more pedantic than other systems with corruptions? Is this in the recording or the playback? 

 

I don't do much LiveTV so it there just recording but when dose happen I usually have stop and exit emby restart and do a few skip to get pass the problem area.

As for other not with SageTV but then again the SageTV HD300 can deal with this can stuff thanks to Sigma Designs hardware decoder really easy unlike Software

Link to comment
Share on other sites

The two HDHomeruns are connected to the same signal splitter so presumably both Emby and Mediaportal were getting basically the same signal. If there was 'signal corruption' coming through then I would have thought I would have seen the same thing on both recordings? Swapping the Homeruns over was an attempt to see if the signal to one Homerun was weaker than the other but no change.  

 

Is it likely that Emby handles 'signal corruption' differently from Mediaportal when recording? I had thought that with H.264 streams the 'recording' was basically just reading the data off the tuner and dumping it straight to disk in an appropriate container. I didn't think that the server was required to do much interpreting the data or error-correction along the way, unlike the good old days of analogue TV signals! :-)

 

The corruption didn't necessarily have to be from the source.  It could have been some hardware moving slightly slowly for a fraction of a second or something else happening on the server right at that time.  My point was just that, the problem occurred at the time of recording so no amount of investigation of playback is probably going to help us determine what that was unfortunately.

Link to comment
Share on other sites

EmbyKiwi

The corruption didn't necessarily have to be from the source.  It could have been some hardware moving slightly slowly for a fraction of a second or something else happening on the server right at that time.  My point was just that, the problem occurred at the time of recording so no amount of investigation of playback is probably going to help us determine what that was unfortunately.

 

@@ebr I completely agree that the corruption appears to be happening during the recording process rather than the playback.  Not knowing 'what gets logged to where' I take it from your comment that the logs I have provided are all about the 'playback' side and therefore useless?  Is there anything logged from the recording process elsewhere that might give me an indication of where the problem lies with my setup?

 

Re other things happening on the server -  it is a fairly clean build with very little added apart from Windows 10 and Emby. The issues have occurred at different times of the day/night so unlikely to be a regular process and, once it starts, it tends to continue intermittently.

 

Given it doesn't seem to occur on 30-60 minute recordings, could it be some buffer/queue that is slowly filling and overloading once the recording gets to  a certain length and .... if so .... would throwing more RAM at it help or is it likely to be coded to a certain size? 

 

Thanks for any help/suggestions that you can provide.

Link to comment
Share on other sites

dranderson402

I've notice that if I start watching a recording in process, the point of the recording when I started watching will get a lot of corruption and pixelate at times for the remainder of the recording. For example, I recorded Survivor last night. We started watching the recording in progress 30 minutes in to the show. We do this to skip the commercials. By the time I reached the 30 minute mark in the recording (when we started watching) I start to notice the corruption. Seems corruptions might be around the time I ffwd the commercials. So possible that extra activity is corrupting the recording.

Link to comment
Share on other sites

EmbyKiwi

@@dranderson402

Sounds like you watch TV the way we do... permanently in catch-up mode and skipping the ads! :-)

 

Your theory is certainly a possibility/likely with some of the recordings where we were fast forwarding through over an hour of pre-game show before the start of the game itself. Others however were played very late at night so I watched them the next morning, well after they had finished recording, and they also started glitching at around the 1:20-1:30 mark. Similarly, with my setup, I have not noticed the issue when catching up shorter shows (up to an hour).

 

It is a bit frustrating that my old Mediaportal server is on much older hardware and has lots of other things running on it and yet it copes with recording and catching up during recording quite happily. Emby has been an awesome solution for us in many ways and is much better than my old solution in lots of areas.... but we do still watch recorded TV and keeping Mediaportal going for anything longer than an hour seems a bit silly! :-) Hopefully someone can point me in the direction of what I'm doing wrong. :-)

Link to comment
Share on other sites

dranderson402

I do remember back in my MythTV days and using older hdhr units, before the dnla days, I had to keep my hdhr's on a separate network. Otherwise I would kill the recordings if I was watching anything. Back then with the linux driver for the hdhr there wasn't any flow control or error correction. So a dropped packet from the hdhr was just lost.

 

Also, I have some very old drives I record to. It's possible I may be seeing bad spots. I half doubt it because it only happens on CBS shows which broadcast in 1080i. The other stations are 720p. But I do know if I let the show record and not watch it till after the recording finishes, then I don't have this problem.

Link to comment
Share on other sites

EmbyKiwi

Interesting point! I'll have another look at how my HDHRs are connected and where the traffic is going to get to the server etc in case there is a bottleneck somewhere. Pretty much all networking is Gigabit back to a 16-port Gigabit switch but there are some devices sharing a 5-port/8-port GB switch where there are more devices than wall ports so worth checking. 

 

My recording drive is a fairly new 1TB SSD so hopefully that is not the issue! Following @@somedude's comments above I did check to see if there were any errors on the drive and it looked OK. Interesting that you you are seeing it more on 1080i than 720p.  I hadn't thought to see if some channels are worse than others. ANother thing to look into! :-) 

Thanks

Link to comment
Share on other sites

I've notice that if I start watching a recording in process, the point of the recording when I started watching will get a lot of corruption and pixelate at times for the remainder of the recording. For example, I recorded Survivor last night. We started watching the recording in progress 30 minutes in to the show. We do this to skip the commercials. By the time I reached the 30 minute mark in the recording (when we started watching) I start to notice the corruption. Seems corruptions might be around the time I ffwd the commercials. So possible that extra activity is corrupting the recording.

 

That's very interesting.  If you can reliably reproduce that with logs, please do.

 

Thanks!

Link to comment
Share on other sites

dranderson402

@@ebr That is truely speculation on my part. But I will see if I still have the logs of when Survivor last recorded and I watched. I'll pull them.

Link to comment
Share on other sites

Here are my logs for the recording of and watching Survivor. Recording started at 18:59. I started watching at 19:37.

 

And does the timing of the corruption in the recording match up exactly with the timing of you starting watching or fast forwarding?

Link to comment
Share on other sites

dranderson402

And does the timing of the corruption in the recording match up exactly with the timing of you starting watching or fast forwarding?

Yes. I just went back to the episode and the corruption started at 39 minutes into the show. I started watching at 37 minutes into the show. When I first started watching I did 2 right clicks to jump 1 minute forward to get past the 1 minute early start. Then I would jump past all ad breaks.

 

Sent from my SM-G955U using Tapatalk

Link to comment
Share on other sites

dranderson402

For what it's worth. I recorded 911 on Fox last night and started watching the recording 20 minutes into the show. Every time I ffwd through ads I noted the time. This way I can see if my ffwding had any affect at the noted time in the recording. For example, at 44 minutes in to the show's recording, I was at 20ish minutes into watching and did a ffwd. At 44 minutes into watching I noticed playback corruption.

 

So now the questions are...

 

Too many read/writes and my hard drives can't keep up?

Packet loss or collisions as both my Shield TV and HDHR's are both slamming the nic in the computer?

Or maybe my I5 computer just can't keep up?

 

I don't remember when I started seeing this issue so I don't know what the problem really is. Did my logs show anything to what the problem might be?

 

My hdd's are old. They are 4 seagate constellations in raid 5. They are maybe 5 years old or more. Might be time to finally build that unraid server.

Edited by dranderson402
Link to comment
Share on other sites

  • 2 months later...
EmbyKiwi

Yes.

 

I've been trying to identify when the problem occurs as there are some recordings where it is perfect, and others with varying degrees of interference. The comments above from @@dranderson402 seem to be accurate that if you join a program part way through recording and skip forward to the start of the program (assuming a buffer at the start), then there will be glitching at the point it was recording when you skipped ahead. This repeats as you skip the adverts later on, assuming the recording was still occurring. 

 

I suspect the reason I first noticed it in the rugby was that these were very long recordings with lots of pre-game and I was skipping through lots of it while it was still recording... creating lots of glitching further into the recording when I caught up to it.

 

We have generally tried not to watch programs until they have finished recording to see if the problem improves (and it seems to have) but that is not really a solution for late night sport in particular. 

 

I am also trying to see whether skipping forward in one program being recorded also affects other programs being recorded at that time, but recording multiple channels is less common than it used to be.

 

Not sure if this is the only cause but it certainly seems to be a contributing factor.

 

Cheers

.

Link to comment
Share on other sites

dranderson402
.....

 

We have generally tried not to watch programs until they have finished recording to see if the problem improves (and it seems to have) .....

 

^^^^^ This for me as well.

Link to comment
Share on other sites

dranderson402

FYI, My system was recording 3 shows at 7pm. The Resident, NCIS both for 1 hour and The Conners for 30 minutes. I started watching The Resident about 7:20ish. I noticed the pixelation later in the show at the times I skipped forward to skip commercials. When we finished that show, we started NCIS and it had the same corruption pixelation at the same times I skipped forward while watching The Resident.

 

Let me know if you want my logs from yesterday and I'll grab them. However, I do need to add that I'm having hard drive issues which very well may be causing the problem. My system has 4 1TB Seagate Constellations in Raid 5. I just recently ran Crystal Disk Info on that system and of those 4 drives 1 shows bad and the other 3 show caution.

 

I'm just now starting my Unraid build but will be using a spare WD My Book on the current system and moving all recordings over to it for now. The My Book uses usb 3 so we'll see if I still have issues after the move.

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...