bruor 31 Posted April 26, 2023 Share Posted April 26, 2023 I've been battling some issues with the Android TV app when used remotely with my emby instance. - The Android TV app is connected via an SSL URL - I'm unable to use the mobile APK on android TV because it fails to play back some live tv streams properly. (will open a separate thread for that). - There is adequate bandwidth between locations, I have 50mbps upstream, client locations have 40mbps downstream. No matter what the stream bandwidth appears to be, I see "reducing max bitrate due to quality setting" server side and the stream is transcoded. This happens for streams that are 20mbps, 10mbps, 8mbps, 3mbps, 2mbps etc. As a workaround I've found that I am required to set the "max streaming bitrate" on each android TV app instance individually. This seems to disable auto bitrate detection and now transcoding only happens if required. Streams up to 20mbps (the highest I seem to have available from my provider), now work without issue so I don't believe BW is actually an issue between the client and server. How can I help contribute to make the auto functionality work a bit better? Or should I focus on getting stream issues with the mobile APK debugged and fixed since that will be taking over in the future? Link to comment Share on other sites More sharing options...
ebr 14929 Posted April 26, 2023 Share Posted April 26, 2023 Hi. The TV app actually tests the speed of your connection just before playback when in auto. Perhaps something is going on on your server at that time that is making that test come back lower than it should. In any case, you have found the proper solution - which is to set it manually if you are sure of the conditions. Link to comment Share on other sites More sharing options...
bruor 31 Posted April 26, 2023 Author Share Posted April 26, 2023 How is the speed test performed? Perhaps I can make some tweaks to my network to ensure that it is uninhibited. Link to comment Share on other sites More sharing options...
ebr 14929 Posted April 26, 2023 Share Posted April 26, 2023 It calls an API on the Emby server to download some data and times the result. Link to comment Share on other sites More sharing options...
bruor 31 Posted April 26, 2023 Author Share Posted April 26, 2023 What's the endpoint named please? Link to comment Share on other sites More sharing options...
ebr 14929 Posted April 27, 2023 Share Posted April 27, 2023 20 hours ago, bruor said: What's the endpoint named please? playback/bitratetest Link to comment Share on other sites More sharing options...
neik 837 Posted April 29, 2023 Share Posted April 29, 2023 On 4/26/2023 at 5:18 PM, ebr said: In any case, you have found the proper solution - which is to set it manually if you are sure of the conditions. I would call it a workaround rather than a solution. "Auto" suggests to be a set and forget but unfortunately it cannot hold up to it. I've been using Emby for a couple of years now and in fact, it never has there were always problems with it. 1 Link to comment Share on other sites More sharing options...
bruor 31 Posted April 29, 2023 Author Share Posted April 29, 2023 I think I've found the reason it tends to detect improperly. If I have multiple clients streaming at the same time, I can see requests stack up in the browser inspect window when streaming video chunks to remote clients, they take much more time to transfer than they do on my internal LAN. This is also reflected in the emby server log by increasing time value on the 200 responses it sends to clients. It seems like the server process only responds to a single request at a time, if a video chunks is being sent to the client and it takes 2-3 seconds to xfer, I can't see more chunk requests and API requests queue up and sit in pending status, until the top one is filled and then it works it's way down the stack. I haven't been able to determine if that's happening globally or per client yet (ran out of time to test). If the API call from the client to test speed is delayed because the server is waiting it could be counting that as extra transfer time maybe. I'm going to try running my server on different hardware too as a test just to rule that out though. Link to comment Share on other sites More sharing options...
neik 837 Posted May 8, 2023 Share Posted May 8, 2023 So much to "auto".. this is on a 300Mbit line to a homeserver (50mbit upload) on the same ISP and only playback ongoing: Link to comment Share on other sites More sharing options...
ebr 14929 Posted May 9, 2023 Share Posted May 9, 2023 19 hours ago, neik said: So much to "auto".. this is on a 300Mbit line to a homeserver (50mbit upload) on the same ISP and only playback ongoing: That's not necessarily incorrect but, if you are certain it should support more than 13Mb in all situations, then you can manually select a higher bitrate. The app's priority has to be to be sure whatever you are playing right now plays well. Link to comment Share on other sites More sharing options...
neik 837 Posted May 10, 2023 Share Posted May 10, 2023 On 5/9/2023 at 3:34 PM, ebr said: The app's priority has to be to be sure whatever you are playing right now plays well. I agree with you on that, I also would prefer to have a little less bandwidth but fine playback rather than the higher bandwidth with buffering. But the gap is just way too big in that example. 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