Jump to content


Photo

Auto bandwidth erratic behavior

1.2.69g auto bandwidth live tv recording

  • Please log in to reply
26 replies to this topic

#1 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 01 November 2016 - 06:56 PM

On one device, I noticed it drops to the absolute lowest bandwidth possible transcoding when it is wired CAT6 10/100/1000 to the server. Power cycling the device did not fix it. This was with a recording.

On multiple devices (wired and wireless), I noticed (mostly live TV but also in recordings) it would pause every few seconds and I couldn't rightly explain how, technically, it is doing that.

In both cases, I changed the bandwidth limit from "Auto" to "40 Mbit/s" and the problems are gone.

Server 3.0.8400.0

#2 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 153382 posts
  • Local time: 08:25 PM

Posted 01 November 2016 - 09:51 PM

Hi there. In order to provide any sort of response to this, please provide the information requested in how to report a media playback issue. thanks !



#3 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 01 November 2016 - 10:21 PM

After posting this, a recording did periodically pause but it was approximately once every five seconds versus once every 10 seconds. Might be coincidence, might not, hard to say. This is an issue that didn't exist a few months back.

It definitely fixed the former where the server is transcoding to a ridiculously low bit rate for no apparent reason.

Attached Files

  • Attached File  logs.zip   622.79KB   2 downloads

Edited by FordGT90Concept, 01 November 2016 - 10:25 PM.


#4 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50887 posts
  • Local time: 08:25 PM

Posted 02 November 2016 - 09:54 AM

The auto setting is subject to a number of anomalies based on circumstance.  Since we test communications with the server to determine the rate, if the server happens to be really busy at the time, the rate could come back artificiality low.

 

This is most likely to happen in a situation where your server is asleep at the time you start the app or just by happenstance it is doing some heavy lifting for some other reason.

 

In those cases, the best bet is to do what you did and set the value to a hard number.



#5 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 02 November 2016 - 05:17 PM

Neither case should be applicable. My server is pretty much idle all of the time and power cycling the Leelbox should have taken care of any kinks on the client side. It happening twice in a row is especially weird.

I think the best solution would be an option like "Max" or "Direct" where it doesn't arbitrarily throttle at all. I'm hoping that if it had such a setting, the remaining of the little pauses would go away (very rare now).

Edited by FordGT90Concept, 02 November 2016 - 05:19 PM.


#6 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50887 posts
  • Local time: 08:25 PM

Posted 02 November 2016 - 05:45 PM

Any "pauses" you are seeing in your playback are not related to the bitrate being requested arbitrarily low - unless they are the result of your server not being able to keep up while transcoding.

 

Edit: Just looked at a couple more of your transcode logs and it does appear your server is not able to keep up.  FPS is dropping below 20 in some cases.



#7 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 02 November 2016 - 06:40 PM

I think the transcode logs was when the picture was horrible. It's difficult for me to figure out the time but he was watching Big Bang Theory...
1) S10E06, he intercoms me and tells me the picture is bad. I go upstairs and look, it's horrifyingly bad.
2) He insists he's almost done watching it, I insist we should try something. He gets a phone call (convinently) so at this point I change the setting from Auto to 40 Mbit/s.
3) I started S10E05 by accident thinking that was the one he was watching. It looks good.
4) I don't remember if he finished S10E05 or finished it but he switched to S10E06 again (it did not save progress, he rewatched the whole thing) and all was well.

Searching the logs...
2016-11-01 15:45:41.9886 Info App: Profile: Android-VLC, Path: \\SERVER\Recordings\The Big Bang Theory\Season 10\The Big Bang Theory S10E05 The Hot Tub Contamination.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: False
2016-11-01 15:47:14.0973 Info App: Profile: Android-VLC, Path: \\SERVER\Recordings\The Big Bang Theory\Season 10\The Big Bang Theory S10E06 The Fetal Kick Catalyst.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: False
2016-11-01 16:10:43.1714 Info App: Profile: Android-VLC, Path: \\SERVER\Recordings\The Big Bang Theory\Season 10\The Big Bang Theory S10E05 The Hot Tub Contamination.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2016-11-01 16:12:08.5212 Info App: Profile: Android-VLC, Path: \\SERVER\Recordings\The Big Bang Theory\Season 10\The Big Bang Theory S10E06 The Fetal Kick Catalyst.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
So 4:12 (4:10 too) is where everything worked correctly.

Note the transcoding logs: the last one starts at 4:09 and is very brief. This period of no transcoding is where it worked perfectly. When the problem surfaced again? 6:52 when I started Meet the Press and it paused twice.

So it appears you're absolutely right that things get bad when transcoding. My argument is that it shouldn't be transcoded at all because these boxes are capable of direct play (yeah framerate dips once in a while but that's far more preferable to transcoding pauses).


The server has a Xeon E3-1230V3. It boggles my mind why it would struggle to transcode a single stream.

Edited by FordGT90Concept, 02 November 2016 - 06:40 PM.


#8 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 153382 posts
  • Local time: 08:25 PM

Posted 03 November 2016 - 02:06 AM

the boxes are capable of direct play but when we did a little test with the server the data wasn't downloaded fast enough to direct play that file. so that's why it was transcoded but it looks like you have figured out how to customize that.



#9 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 03 November 2016 - 06:46 AM

Can you pin down why it wasn't fast enough? The only bottleneck I can think of is the 10/100 Mbit NIC on it but the HDHomeRun is the same. The network is all gigabit.

If it was transcoding on C:, that's reading/writing to a 400+ MB/s SSD. If it was reading/writing on D:, that's a ~200 MB/s HDD.

Is the 40 Mbit setting not enough? What is "auto" checking for specifically? The choppy ones had isEligibleForDirectStream: False

Edited by FordGT90Concept, 03 November 2016 - 06:47 AM.


#10 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50887 posts
  • Local time: 08:25 PM

Posted 03 November 2016 - 08:39 AM

Based on your transcode speeds the box is not a beast in the first place, correct?

 

So, anything that may have been happening at the time we did the bandwidth test could have affected it.  This could be something in Emby server (like a library scan) or something external (like an anti-virus scan taking place).

 

But, as I said above, you've already figured out how to solve this situation properly.  If you know you have adequate bandwidth - you just set the bitrate to the fixed amount.



#11 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 03 November 2016 - 10:35 AM

Big Bang Theory was on Amlogic S905X. Meet the Press was on Amlogic S905.

#12 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 04 November 2016 - 08:03 PM

So...apparently the issue has come back with a vengeance and this time, it wasn't transcoding. She was trying to watch live TV and it kept pausing. After about 45 minutes, she gave up.

Again, nothing changed in the last month or two that this started happening except Emby for Android TV and Emby Server versions.

I'm still not entirely sure how this is even happening because it does end up behind live TV. Since there is no transcoding logs, I have to assume that it is buffering on the Android TV box itself.

Attached Files



#13 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 07 November 2016 - 08:42 PM

I'm convinced something happened in 3.0.8400 or 3.0.8500 that broke playback on all of my Amlogic S905/X boxes. Since 3.0.8500, no matter the bandwidth setting, it's horrible. FFMPEG is running on the server at about 25% CPU load. This is while playing a recording. Logs attached.


Edit: There is a new beta for HDHomeRun available that I'll install when able but I doubt that will improve anything.

Attached Files


Edited by FordGT90Concept, 07 November 2016 - 08:47 PM.


#14 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 153382 posts
  • Local time: 08:25 PM

Posted 07 November 2016 - 08:56 PM

No, the build are almost identical. As a test, can you try disabling throttling under transcoding settings in the server dashboard? thanks.



#15 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 07 November 2016 - 09:48 PM

I disabled throttling with everything else being the same. Not only did it keep pausing every few seconds, it also made the picture quality horrible.

Edited by FordGT90Concept, 07 November 2016 - 09:49 PM.


#16 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 153382 posts
  • Local time: 08:25 PM

Posted 08 November 2016 - 12:26 AM

have you tried lowering the in-app bitrate?



#17 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 08 November 2016 - 01:35 AM

I tried Auto, 40 Mbit, and 30 Mbit. They all behaved the same. Not much interest in going lower than that because it's supposed to be MPEG2-TS direct. MPEG2-TS 1080i -> h.264 can never make my server go over 50% load (not that it should even be doing that). Network is all gigabit except for the HDHomeRun and boxes themselves. Server is capable of shoveling 100+ MB/s (saturate gigabit). There's no triggers in the server that would cause an upset like this (it's a domain controller). I checked when it was happening and the network had lots of bandwidth capacity.

...

I'm getting a very strong impression that the recording itself is FUBAR...

Edit: Verified with MPC-HC, the recording we were trying is FUBAR. The program is "CBS Evening News With Scott Pelley." The recording on the 3rd was perfect (3.2 GB), the recording on the 4th was bad (2.2 GB), and the recording today was horrible (1.6 GB). It is not obvious why so much data was lost.

Gotham which recorded today as well is also FUBAR: 3.0 GB when it should be about 6.2 GB.

...so what happened on the 4th? 3.0.8500 released. The oldest log I have dates back to November 5 and it has version number 3.0.8500.

Edit: And now I see why. I posted on the 4th complaining about massive problems. The logs are attached to that post but, here's the line of importance:
2016-11-04 00:47:02.3559 Info Main: Exiting to perform application update.
The update to 3.0.8500 occurred in between the two CBS News recordings: working (Nov 3rd) and not working (Nov 4th). 3.0.8500 definitely broke something bad.


Now to head back to the topic of the thread...

...I started watching live TV through Edge browser on my computer. First 40-45 seconds were fine but then it started getting into the pausing. Ethernet, RAM, CPU on server were negligible (15% with CPU at 0.83 GHz of 3.30 GHz). By 70 seconds in, the pausing becomes routine. FFMPEG is running.

...now get this, same live program through Emby Theater: zero problems. On the server side: CPU usage is less than 1%. FFMPEG not running.


Pretty clear that transcoding is the problem. It shouldn't be transcoding but when it does, it does a terrible job at it even though there's plenty of hardware resources available to do it.


Edit: attaching logs...

Attached Files

  • Attached File  logs.zip   483.11KB   1 downloads

Edited by FordGT90Concept, 08 November 2016 - 02:30 AM.


#18 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 08 November 2016 - 08:38 PM

Well, I can't test nor verify either of these issues now because I swapped all of my CONNECTs for EXTENDs. The transcoding pausing bug is gone because it's transcoding in the HDHomeRuns and the MPEG2 recording bug is gone because it's now saving MPEG4.

#19 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 153382 posts
  • Local time: 08:25 PM

Posted 09 November 2016 - 12:08 AM

Thanks for the report.



#20 FordGT90Concept OFFLINE  

FordGT90Concept

    Advanced Member

  • Members
  • 720 posts
  • Local time: 07:25 PM

Posted 09 November 2016 - 03:19 AM

I should add that there's still some problems with skipiness (boxes are set to auto bandwidth now) but it no longer full pauses. Usually audio continues on but some frames are dropped. It would be nice to fix that but not entirely sure the best way to do it.





Also tagged with one or more of these keywords: 1.2.69g, auto, bandwidth, live tv, recording

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users