Jump to content


Photo

LiveTv Pause/Glitches in Seek Mode - Not Present in Direct Stream LiveTv

LiveTv Pauses AndroidTv

  • Please log in to reply
91 replies to this topic

#21 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 05 January 2019 - 07:50 PM

Well... This is still happening even when moved back to the default transcode location/SSD where Emby is installed.
Will report back once I get the dedicated NVMe SSD installed, but I'm not optimistic that will solve this.
I'll also test with my other two ATV boxes (1 more shield, other Mibox) for additional information.
Not sure.. Maybe a latency issue, or somehow network related.

#22 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 05 January 2019 - 07:56 PM

I take back the network related comment, that seems solid considering the lack of this issue when direct playing, and local file playback. Also, this doesn't happen with Theater when playing LiveTv, however I get it doesn't have to transcode/direct stream either.

#23 cayars ONLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2442 posts
  • Local time: 07:15 PM

Posted 05 January 2019 - 11:27 PM

It would seem that your original HDD was fine considering the SDD didn't help.  Looking back at your 1st post I have a question for you.

What happens if you set the Shield to downmix audio to stereo (for trouble shooting purposes)?

 

Have you tried that?

 

Does it do this on many TV channels or only 1 or 2?



#24 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 06 January 2019 - 11:07 AM

It would seem that your original HDD was fine considering the SDD didn't help. Looking back at your 1st post I have a question for you.
What happens if you set the Shield to downmix audio to stereo (for trouble shooting purposes)?

Have you tried that?

Does it do this on many TV channels or only 1 or 2?


I've recently tested downmix to stereo, but it is still an issue with that setting as well.
This is present on all channels (both OTA and CC HDHR's), however the higher bitrate ones (or at least 1080 vs 720) seem to be a bit more problematic.
If I get some time I'll spin up a new Emby Docker for testing to see if present. I'll also test with a Windows Emby install to see if for some reason this is environment dependent.

#25 roppy84 OFFLINE  

roppy84

    Member

  • Members
  • 10 posts
  • Local time: 04:15 PM

Posted 06 January 2019 - 12:31 PM

I just want to throw my 2cents in. I have the same set up (Unraid, Emby Docker Beta, HD Homerun Quatro, and Shield TV) and I have the exact issue. Everything I have tried does not fix it except pausing the live stream for a second or two then resuming.

Sent from my Nexus 6P using Tapatalk
  • bungee91 likes this

#26 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 06 January 2019 - 02:26 PM

I just want to throw my 2cents in. I have the same set up (Unraid, Emby Docker Beta, HD Homerun Quatro, and Shield TV) and I have the exact issue. Everything I have tried does not fix it except pausing the live stream for a second or two then resuming.

Sent from my Nexus 6P using Tapatalk


Someone's starting to think this is an FFMPEG issue with the Docker (that'd be me;or I'm wrong, but you having the same issue is helping to narrow this down)... =P

#27 cayars ONLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2442 posts
  • Local time: 07:15 PM

Posted 07 January 2019 - 05:12 AM

You guys do have a few things in common.  Have either of you guys ran any IO benchmarks inside of docker and outside of docker to see if you are limited in some way on IO either for networking or disk IO?

 

I just googled docker performance issues and saw a few mentions of this type of thing depending on how things are mounted.  I myself don't use docker so I'm not really much help other than suggesting to take a quick look at this from a logical standpoint and testing the container vs host for throughput just to see if something is limited in some way.  Sort of process of elimination. :)


  • bungee91 likes this

#28 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 07 January 2019 - 11:36 AM

You guys do have a few things in common.  Have either of you guys ran any IO benchmarks inside of docker and outside of docker to see if you are limited in some way on IO either for networking or disk IO?

 

I just googled docker performance issues and saw a few mentions of this type of thing depending on how things are mounted.  I myself don't use docker so I'm not really much help other than suggesting to take a quick look at this from a logical standpoint and testing the container vs host for throughput just to see if something is limited in some way.  Sort of process of elimination. :)

 

I have not as of yet, but it's certainly on my list to diagnose this.

I should have some time this week to properly test multiple scenarios, and diagnose the underlying issue (or at least get to the point that it must be X).

Currently the Emby Docker mapping is pointed directly at mnt/ so I can access any location directly (not exactly sure how Docker/UnRAID have that internally setup). It looks as if for testing I could technically point the transcode location to /tmp and would then write directly to RAM. That should rule out disc based IO or not.

Pending that ram transcode temp (if the issue is not present), when I get the NVMe drive (Amazon failed me), I plan to test with it just pointed to its mount point, however I should also be able to directly assign it as a block level device directly to Emby, and see if that resolves however the /mnt is routed from Docker.

 

I did test with my new ShieldTv (refresh version) in my bedroom, which is set to downmix to stereo, directly hooked to the Tv.

I still get the initial glitch within the first 10-20 seconds of the stream starting (this has ALWAYS happened, would be super interested to see if this happens for other with it direct streaming (doesn't happen with direct play)), however after that initial glitch, all seemed well.

The problematic ShieldTv is the original/larger version. I will likely swap the newer/smaller one in the place of the older/bigger one, and test to see if the issue is then present. I know the Chipset is the same for both ShieldTv's, but it is odd to me that one has the issue, and the other seems okay (in limited testing).

 

More to come when I have time to run this testing. For now, start channel, pause for 3-4 seconds, all is well until I change the channel.  :P



#29 cayars ONLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2442 posts
  • Local time: 07:15 PM

Posted 07 January 2019 - 11:52 AM

It too often get the one off glitch when tuning to a new channel when it may briefly pause then resume and be fine.  Others have also commented on this in the past so you are no alone with this.  It''s not really a big deal to me as I just expect it to happen since Emby is remuxing/direct streaming it (repackage). :)

 

I'd describe it as it almost seems like it starts playing whatever is in the buffer partially filled, uses this data up, then waits very briefly for the buffer to refill.  Then it just works.



#30 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 07 January 2019 - 12:15 PM

Thanks for confirming that, as I was never sure if it was related to my issue or not. 

Well I won't try to fix that while diagnosing my other issue.  ;)


  • cayars likes this

#31 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 10 January 2019 - 09:03 PM

Additional testing, and also some changes to my initial thoughts/assumptions on this issue.

 

Forcing a full transcode resolves this issue, no more glitches (except for that very first one ~10 seconds into the start of the stream)!

This issue is only present when remux/direct stream is happening. 

I get glitches on all my ATV (ShieldTv, MiBox, Nexus player) devices under this condition, however it is more often on the ShieldTv set to 5.1 (auto) audio setting.

 

If I set the max bitrate to something less than the stream (forcing the full transcode), it's all good.

This will take some time, but I will setup a Windows Emby server, and test if a remux/direct stream has this issue or not.

 

I will say that I LOADED my server, with disc benchmarks, CPU stressing, network load, and it didn't cause this to be any different, worse, etc.... I think for some reason the direct stream just gets out of sync with the video, and because of that it glitches. I may attempt updating FFMPEG in the Docker to see if it resolves this issue. I assume it will break some other things (hardware acceleration that I don't use, etc...), however it'd be a worthwhile experiment to be able to easily reverse.

 

Unless whatever joins the remuxed audio back with the video is not FFMPEG, and I'm just wasting my time... Uncertain, any input on that is much appreciated.



#32 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 11 January 2019 - 01:41 PM

Adding to yesterday's post...

 

I may have confused "direct streaming" with my comments regarding the audio being remux'd, so I did some reading, and have screenshots from the playback yesterday (logs throughout this thread are here as well for conforming).

In the tests ran, is the "direct stream" that causes my issues to appear a container swap, OR is it a remux of the audio (or both)?

Pics of the stats for nerds attached. Same channel, just one using 5.1 audio, and the other downmixed to stereo. In both cases the issue is present.

 

5.1

5c38d5000bb48_51Small.jpg

 

Downmixed

5c38d5117dc86_DownmixSmall.jpg

 

Just trying to narrow this down.. Super annoyed by having to pause each time to fix.

I've considered forcing a transcode for now just to remove the issue, but that would be unfortunate to do long term.



#33 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 121604 posts
  • Local time: 07:15 PM

Posted 11 January 2019 - 02:10 PM

So that does resolve it?

#34 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 11 January 2019 - 03:05 PM

So that does resolve it?

 

Forcing a transcode does resolve this issue, correct.

What would be the recommended next steps to fix or diagnose?  :huh:



#35 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 121604 posts
  • Local time: 07:15 PM

Posted 11 January 2019 - 03:09 PM

That makes it seem like the issue is in the source stream.



#36 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 11 January 2019 - 03:23 PM

That makes it seem like the issue is in the source stream.

 

I may be misinterpreting this, so do you mean a network issue?

If so, I can't see how given other testing, use cases, and other apps not having this issue. That and direct play is perfect, and the tuners themselves are without issue in testing.

To me is seems like the magic happening to swap containers or remix audio is causing minor dropouts/glitches in that stream. If that's what you're saying (whatever is coming out of Emby and being passed to the client is having an issue) then I'd agree.

Let me know what I can do to provide more testing/details, or perform to get this resolved. Much appreciated.



#37 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 15 January 2019 - 09:32 PM

That makes it seem like the issue is in the source stream.

 

Any additional help in troubleshooting this (or additional explanation of your theory) is much appreciated.

 

Also, I tested this condition with a newly installed Emby Server Windows install on a completely different desktop and had the same results (glitch/dropouts).

My only other testing/suspicion would be my network switch, since a LiveTv stream is handling I/O that is time sensitive between HDHR, Server, ATV client. 

That's the only remaining culprit here.

Again, pause a couple of seconds (build up buffer), and all is well. You could also just increase this buffer in the ATV app, and it would alleviate my issue as well.  :o

 

Edit: I take that back about the network switch being a potential culprit, as this issue would be present in direct play, and it is perfectly fine there. Nothing more I can think of to troubleshoot... Likely only an issue with ATV devices, but I only have PC's/Theatre to test otherwise, and those direct play without any muxxing, and work (as expected) perfectly in this situation.


Edited by bungee91, 15 January 2019 - 09:59 PM.


#38 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 121604 posts
  • Local time: 07:15 PM

Posted 17 January 2019 - 10:18 PM

Do you see this in the web app?



#39 bungee91 OFFLINE  

bungee91

    Advanced Member

  • Members
  • 285 posts
  • Local time: 06:15 PM

Posted 18 January 2019 - 10:28 AM

Do you see this in the web app?

 

I'm not sure, I rarely use it for playback.

I've just changed some things around, give me some time to report back after some testing.

 

This still being present using a different computer/Emby Server install pretty much ruled out most possible issues, but I still made some changes.

I added in a new network switch, and have all HDHR's, Server/Emby, and ShieldTv client on it (this is the only variable that would impact both the server/docker install, and the test Windows Emby server).

Updated Emby Docker install location, and transcoding temp to an NVMe PCIe SSD. Assigned Emby Docker it's own NIC in the server.

 

My initial test looked good, but it was very brief. I did still get the initial glitch within ~10-20 seconds of the stream starting (as discussed above; post #28/29), @Luke @ebr any reason why that issue cannot be resolved? I'm now hyper sensitive to these glitches, so it happening basically every time I tune to a channel just makes me think it will be continuous (and in my case that's pretty likely)  ;)



#40 ebr ONLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 42835 posts
  • Local time: 07:15 PM

Posted 18 January 2019 - 12:12 PM

I did still get the initial glitch within ~10-20 seconds of the stream starting (as discussed above; post #28/29), @Luke @ebr any reason why that issue cannot be resolved? I'm now hyper sensitive to these glitches, so it happening basically every time I tune to a channel just makes me think it will be continuous (and in my case that's pretty likely)  ;)

 

Most people do not see this (I don't) and to "fix" it requires delaying the start time for live TV - very undesirable.







Also tagged with one or more of these keywords: LiveTv, Pauses, AndroidTv

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users