Jump to content

On Remux, Android TV times out "Too many errors"


bradford
 Share

Recommended Posts

bradford

Emby Server: 3.1.1 (on pre-3.1 version, didn't error, just spun),  Ubuntu (lxc container)

Client: Android TV

 

I can play from the beginning, but when I try to start play 10 minutes in I get the error "Too many errors. Giving up." in the client. The same thing happens 5 minutes in, and when I try to skip ahead quickly.

 

It looks like, from the logs, that it's remuxing from the beginning, and maybe it's timing out? I'm not sure. Direct play media works fine. Thanks for the help.

server.Log.txt

Edited by bradford
Link to comment
Share on other sites

bradford

I have a short memory, it seems, since I forgot about my previous, similar post: https://emby.media/community/index.php?/topic/41144-transcoding-to-shield-tv-broken-unable-to-write-data-to-the-transport-connection-the-socket-has-been-shut-down/&do=findComment&comment=383425

 

It appears that the new version removed or changed where I can set the ffmpeg version, and it is using the installed one 3.3.2, which per the last thread is untested and likely contributing to the issue.

 

I've spent around 10 minutes looking for the new ffmpeg setting in 3.1.1 and can't find it. Any clues?

Link to comment
Share on other sites

bradford

Nothing that requires transcoding or remuxing is working now, except when I chromecast - am I crazy or was the option to change the FFMPEG location moved or removed? 

Edited by bradford
Link to comment
Share on other sites

I am on 3.1.1 running on a CentOS 7.3 VM and I still have the setting on the "Transcoding" page. Also I had the same problems as you do using ffmpeg 3.2+

  • Like 1
Link to comment
Share on other sites

maegibbons

Apparently it is OS version specific.  Foe example for Ubuntu 16.04 it does NOT show as an option which is a shame.

 

See Luke's response in https://emby.media/community/index.php?/topic/42735-custom-ffmpeg-path-gone/

 

ffmpeg version is the root of many problems and not having a way to specifically test and/or use permanently a specific version is a backwards step IMHO. The option to select as specific ffmpeg should be re-instated.

 

A WARNING could be included to state something like "System version is recommended"

 

Krs

 

Mark

Edited by maegibbons
  • Like 1
Link to comment
Share on other sites

bradford

Thanks both for the response. Now that I know I'm not insane I can understand automatically using the system installed ffmpeg, but I think there should at least be an explanation on the transcoding page. I hope we can figure out what is causing new versions of ffmpeg to fail.

Edited by bradford
Link to comment
Share on other sites

bradford

I uninstalled the package manager ffmpeg and restarted emby server - now I see the option to specify the ffmpeg binary return. I guess when I eventually compile ffmpeg for nvenc support I'll need to see which version actually works with emby...

 

In any case, I still can't skip forward in a remux at all - with emby now using the provided ffmpeg, any attempt to skip foward in the media file results in what appears to be a timeout exception in the logs.

Edited by bradford
Link to comment
Share on other sites

I uninstalled the package manager ffmpeg and restarted emby server - now I see the option to specify the ffmpeg binary return. I guess when I eventually compile ffmpeg for nvenc support I'll need to see which version actually works with emby...

 

In any case, I still can't skip forward in a remux at all - with emby now using the provided ffmpeg, any attempt to skip foward in the media file results in what appears to be a timeout exception in the logs.

 

Hi, we're sorry to hear about this. In order for us to best help you, please provide the information requested in how to report a media playback issue. thanks !

Link to comment
Share on other sites

Well I did some more tests and I can't resume/rewind/fast forward videos that are "direct streamed" to my Nvidia Shield using Emby for Android TV.

I tried various ffmpeg versions (3.1.4, 3.1.5, ffmpeg-git-20160215-64bit-static), using nginx reverse proxy (with/without http2) or directly connecting to emby 8920, different tmp paths (local/nfs) but nothing worked.

 

Emby Theater, Web Player, Emby for Android work fine. Just remuxed videos on Android TV do not (Direct Play & transcoding work fine).

According to the logs the server keeps creating the remuxed file in the specified temp folder without problems after fast forwarding. The screen jumps to the frame it is supposed to continue playing from but just stays there.

This also happened before emby server 3.1.

 

Here are some logs of one instance where I fast forward around 30 seconds in. I can't see any obvious error aside from:

"System.IO.IOException: Unable to write data to the transport connection: Connection reset by peer. ---> System.Net.Sockets.SocketException: Connection reset by peer"

which also happens on other devices when I fast forward which continue anyways though (just a message that the old connection was closed since a new ffmpeg process starts I assume?).

 

My current workaround is setting the allowed bitrate low enough to force transcoding.

ffmpeg_remux_start.log

ffmpeg_remux_fastforward.log

server.log

Edited by xenu
  • Like 1
Link to comment
Share on other sites

There are still some limitations with the TLS implementation in the mono runtime. do you need to be going through your external address? if you can just connect over the lan that will resolve it. I think the upcoming 4.8 will resolve it once and for all because they are adopting Google's BoringSSL:

 

http://www.mono-project.com/docs/about-mono/releases/4.8.0/

Link to comment
Share on other sites

bradford

There are still some limitations with the TLS implementation in the mono runtime. do you need to be going through your external address? if you can just connect over the lan that will resolve it. I think the upcoming 4.8 will resolve it once and for all because they are adopting Google's BoringSSL:

 

http://www.mono-project.com/docs/about-mono/releases/4.8.0/

 

What makes you think it's a TLS issue? I ask because I have the same behavior but I don't connect over TLS (afaik) on my LAN, which is where I see the behavior. I haven't gotten around to submitting the logs, but I didn't see anything besides the socket connection mentioned above. 

  • Like 1
Link to comment
Share on other sites

I think your issue is different and this other user just piggybacked into your thread instead of creating their own.

Link to comment
Share on other sites

bradford

I think your issue is different and this other user just piggybacked into your thread instead of creating their own.

The problems he described sound just like mine... I think he typo'd when he said direct play can't skip, because later he says transcoded files can't skip and direct play works fine. 

 

In either case, I'll wait for @@xenu to clarify, and try to do some testing for this after I test out my shiny new ffmpeg for nvenc capabilities. 

  • Like 1
Link to comment
Share on other sites

Hello,

 

I created a new topic in case our issues are not related as I do not get any error message on the client:

https://emby.media/community/index.php?/topic/43145-no-resumeseek-with-remuxed-videos/

 

but just to recap:

direct stream / remux = no resume/seek

transcode = all good

direct play = all good

 

disabling ssl and/or accessing emby 8096/8920 directly with no reverse proxy did not seem to fix the issue.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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
 Share

×
×
  • Create New...