bradford 5 Posted December 26, 2016 Share Posted December 26, 2016 (edited) 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 December 26, 2016 by bradford Link to comment Share on other sites More sharing options...
bradford 5 Posted December 26, 2016 Author Share Posted December 26, 2016 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 More sharing options...
bradford 5 Posted December 27, 2016 Author Share Posted December 27, 2016 (edited) 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 December 27, 2016 by bradford Link to comment Share on other sites More sharing options...
xenu 10 Posted December 27, 2016 Share Posted December 27, 2016 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+ 1 Link to comment Share on other sites More sharing options...
maegibbons 1267 Posted December 27, 2016 Share Posted December 27, 2016 (edited) 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 December 27, 2016 by maegibbons 1 Link to comment Share on other sites More sharing options...
bradford 5 Posted December 27, 2016 Author Share Posted December 27, 2016 (edited) 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 December 27, 2016 by bradford Link to comment Share on other sites More sharing options...
bradford 5 Posted December 27, 2016 Author Share Posted December 27, 2016 (edited) 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 December 27, 2016 by bradford Link to comment Share on other sites More sharing options...
Luke 37065 Posted December 27, 2016 Share Posted December 27, 2016 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 More sharing options...
xenu 10 Posted December 29, 2016 Share Posted December 29, 2016 (edited) 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 December 29, 2016 by xenu 1 Link to comment Share on other sites More sharing options...
Luke 37065 Posted December 29, 2016 Share Posted December 29, 2016 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 More sharing options...
bradford 5 Posted December 29, 2016 Author Share Posted December 29, 2016 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. 1 Link to comment Share on other sites More sharing options...
Luke 37065 Posted December 29, 2016 Share Posted December 29, 2016 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 More sharing options...
bradford 5 Posted December 29, 2016 Author Share Posted December 29, 2016 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. 1 Link to comment Share on other sites More sharing options...
xenu 10 Posted December 30, 2016 Share Posted December 30, 2016 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. 1 Link to comment Share on other sites More sharing options...
artur.wis 0 Posted January 8, 2017 Share Posted January 8, 2017 Same problem on SONY Android TV Link to comment Share on other sites More sharing options...
Luke 37065 Posted January 8, 2017 Share Posted January 8, 2017 Same problem on SONY Android TV Hi @@artur.wis, we're very sorry to hear about your issue. In order for us to best help you with this, please provide the information requested in how to report a media playback issue. thanks ! Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now