Guest asrequested Posted January 13, 2020 Share Posted January 13, 2020 I believe I did report that, and nothing was done. That was a while ago, though. I've not used auto, since. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 13, 2020 Share Posted January 13, 2020 But the thing is, that this has failed in every app that I've tried. I ran into this issue over the weekend when I was visiting my parents. I had to manually set the rate on their Roku TV or it looked like crap. Last time I checked, bandwidth detection worked fine with the Roku. Today I tried: Web App in Chrome Desktop => bandwidth detection worked Android App => bandwidth detection worked I believe I did report that, and nothing was done. That was a while ago, though. I've not used auto, since. Well, if you had reported it similar as above - like "failed in every app" then I wouldn't wonder. Link to comment Share on other sites More sharing options...
Guest asrequested Posted January 13, 2020 Share Posted January 13, 2020 Ha! Yeah that would be too generic But I meant I reported it in the Theater forum, with what I believe was sufficient specificity. But as I said, it's been a while. I'd have to dig, to find it. But if I ever experience it again, I shall be sure to use the required format. You know what might good, is to employ reporting a new issue similar to mpv. It takes you to prescribed formats on how to report. It's very useful. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 13, 2020 Share Posted January 13, 2020 I ran into this issue over the weekend when I was visiting my parents. I had to manually set the rate on their Roku TV or it looked like crap. I agree that it's easy for an advanced user... which my parents are not. Maybe there could be an option server side that is overall or per user that tells Emby to ignore the app rate if set to Auto or > a defined cap. That internet streaming bitrate limit already exists on a Global and User level. Adding an advanced toggle for an admin for ignoring local limits globally or per user could be very useful in the interim. If enabled, The server automatically shoots for that speed. If it can direct stream within that limit, it does. If it needs to transcode... it will, but to that level. I'm afraid, but that doesn't make the slightest bit of sense. The reasons are so obvious that I don't feel that I need to explain. Link to comment Share on other sites More sharing options...
BAlGaInTl 279 Posted January 13, 2020 Share Posted January 13, 2020 I'm afraid, but that doesn't make the slightest bit of sense. The reasons are so obvious that I don't feel that I need to explain. I guess I'm missing something then. There is a problem with the detection working from what I've read. When this happens, it drops to 1.5 even though you (an admin) know that higher rates are possible. Forcing a limit could allow you to circumvent the original detection in remote streaming situations. Yes, I understand that could cause other issues, but nothing greater than what's already broken. If it's not possible, that's fine, just say that. Saying that it's obvious as to why it doesn't make sense is a bit demeaning. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 13, 2020 Share Posted January 13, 2020 If it's not possible, that's fine, just say that. Saying that it's obvious as to why it doesn't make sense is a bit demeaning. Yes, you are right, I just got a bit tired. Give me some time, I'll explain later. 1 Link to comment Share on other sites More sharing options...
BAlGaInTl 279 Posted January 13, 2020 Share Posted January 13, 2020 Yes, you are right, I just got a bit tired. Give me some time, I'll explain later. No worries. I'm not upset. You don't have to explain. I fully understand that I "don't" understand the inner workings of Emby. I get that the "better" way to approach it is to make it work as intended with specific examples (as you pointed out) rather than kludging together fixes that may work for some, and break it worse for others. Link to comment Share on other sites More sharing options...
Jdiesel 1114 Posted January 13, 2020 Share Posted January 13, 2020 Maybe as a short term solution the fallback bitrate can be increased slightly. 1.5Mbps is just not enough for even the most forgiving viewer. Even my parents would message me to tell me the videos looked bad when they were using my server and they can tolerate at lot. Even a slight bump to 2.0Mbps or even 2.5Mbps would go a long way. This doesn't really solve the root problem and still can introduce unnecessary transcoding but I personally don't care if it is direct playing, direct streaming, or transcoding as long as it works and the end product looks decent. Link to comment Share on other sites More sharing options...
Jonathan1683 24 Posted January 13, 2020 Author Share Posted January 13, 2020 Sorry if I posted this in the incorrect forum. I noticed it was doing it with every client as well and assumed it was a server side issue. The topic name could have been wrong, but I have done my best to explain my issue. I really wanted to have something like what BAI is asking for that's why i asked if it was even working to begin with (setting the video play back in user preferences to a specific bitrate) in my experience it doesn't work remotely. I even logged in under their name and changed it and it also didn't seem to work. So my guess is that this only works if you login locally on that specific device and change it. I was hoping I can just see what user was logged in a see 1.5 and change their bitrate manually (force it to try) I would like it to work automatically, but that seems to be an issue so I was hoping that work-a-round would be easier to implement. I dont care which way you fix it I just wanted a little more control over it in the admin panel. Everyone I have on it has at least a 60mbit connection so I know they have bandwith available under normal circumstances. Sorry for all the trouble and thanks for your assistance. Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted January 13, 2020 Share Posted January 13, 2020 Maybe as a short term solution the fallback bitrate can be increased slightly. 1.5Mbps is just not enough for even the most forgiving viewer. Even my parents would message me to tell me the videos looked bad when they were using my server and they can tolerate at lot. Even a slight bump to 2.0Mbps or even 2.5Mbps would go a long way. This doesn't really solve the root problem and still can introduce unnecessary transcoding but I personally don't care if it is direct playing, direct streaming, or transcoding as long as it works and the end product looks decent. As mentioned earlier this has changed to 3.0Mbps in the current beta cycle. https://emby.media/community/index.php?/topic/79153-force-higher-bitrates/?p=829846 Link to comment Share on other sites More sharing options...
Jdiesel 1114 Posted January 13, 2020 Share Posted January 13, 2020 As mentioned earlier this has changed to 3.0Mbps in the current beta cycle. https://emby.media/community/index.php?/topic/79153-force-higher-bitrates/?p=829846 Ah I missed that, thanks. Link to comment Share on other sites More sharing options...
BAlGaInTl 279 Posted January 13, 2020 Share Posted January 13, 2020 Ah I missed that, thanks. Yeah... I think that will actually help a lot. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 13, 2020 Share Posted January 13, 2020 I'm afraid, but that doesn't make the slightest bit of sense. The reasons are so obvious that I don't feel that I need to explain. I guess I'm missing something then. There is a problem with the detection working from what I've read. When this happens, it drops to 1.5 even though you (an admin) know that higher rates are possible. Forcing a limit could allow you to circumvent the original detection in remote streaming situations. Yes, I understand that could cause other issues, but nothing greater than what's already broken. If it's not possible, that's fine, just say that. Saying that it's obvious as to why it doesn't make sense is a bit demeaning. The transcoding-bandwidth cannot be managed globally at the server side because bandwidth-selection is specific to each individual playback situation and the server doesn't know anything about it. It's solely up to the client side to make that decision - either automatically (detecting bandwidth) - or manually (fixed quality set by the user). The server just cannot know what's right for the client, because what's right for the client can change any minute. What comes on top is that we don't have any 'per-client' settings at the server side. That value that you suggested to (mis-)use is a 'per-user' setting. Now let's assume, that we would use this setting to control the bandwidth. That user might use 3 devices to connect to Emby: 1. Laptop Sometimes used at home, sometimes in a hotel => What kind of value do you set for the bandwidth at the server? 2. Android Mobile Sometimes used at home, sometimes at work (WiFi), sometimes in the subway (low-bandwidth cellular) => What kind of value do you set for the bandwidth at the server? 3. TV Always at home, you want to have maximum bandwidth => What kind of value do you set for the bandwidth at the server? Now, in case you have thought about how to find a compromise for each: 1, 2 and 3 while reading, you need to be aware that it's not about finding 3 values... ...it's just a single value. I hope this example illustrates why it doesn't make sense to let the bandwidth be controlled by a server-side setting. What does makes sense - and is valid within the overall logic including client and server behavior - is that what we have right now: A bandwidth limit. But this is to protect the server-side (or rather the internet connection there). 1 Link to comment Share on other sites More sharing options...
BAlGaInTl 279 Posted January 13, 2020 Share Posted January 13, 2020 The transcoding-bandwidth cannot be managed globally at the server side because bandwidth-selection is specific to each individual playback situation and the server doesn't know anything about it. It's solely up to the client side to make that decision - either automatically (detecting bandwidth) - or manually (fixed quality set by the user). The server just cannot know what's right for the client, because what's right for the client can change any minute. What comes on top is that we don't have any 'per-client' settings at the server side. That value that you suggested to (mis-)use is a 'per-user' setting. Now let's assume, that we would use this setting to control the bandwidth. That user might use 3 devices to connect to Emby: 1. Laptop Sometimes used at home, sometimes in a hotel => What kind of value do you set for the bandwidth at the server? 2. Android Mobile Sometimes used at home, sometimes at work (WiFi), sometimes in the subway (low-bandwidth cellular) => What kind of value do you set for the bandwidth at the server? 3. TV Always at home, you want to have maximum bandwidth => What kind of value do you set for the bandwidth at the server? Now, in case you have thought about how to find a compromise for each: 1, 2 and 3 while reading, you need to be aware that it's not about finding 3 values... ...it's just a single value. I hope this example illustrates why it doesn't make sense to let the bandwidth be controlled by a server-side setting. What does makes sense - and is valid within the overall logic including client and server behavior - is that what we have right now: A bandwidth limit. But this is to protect the server-side (or rather the internet connection there). Thanks for the explanation. I see how my idea falls apart as soon as a devices moves to a different environment. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 13, 2020 Share Posted January 13, 2020 Thanks for the explanation. I see how my idea falls apart as soon as a devices moves to a different environment. When you say that there's a stable and constant environment and network connection - why not simply select e.g. 20Mbps in the client and leave it like that? Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 13, 2020 Share Posted January 13, 2020 Sorry if I posted this in the incorrect forum. I noticed it was doing it with every client as well and assumed it was a server side issue. The topic name could have been wrong, but I have done my best to explain my issue. I really wanted to have something like what BAI is asking for that's why i asked if it was even working to begin with (setting the video play back in user preferences to a specific bitrate) in my experience it doesn't work remotely. I even logged in under their name and changed it and it also didn't seem to work. So my guess is that this only works if you login locally on that specific device and change it. I was hoping I can just see what user was logged in a see 1.5 and change their bitrate manually (force it to try) I would like it to work automatically, but that seems to be an issue so I was hoping that work-a-round would be easier to implement. I dont care which way you fix it I just wanted a little more control over it in the admin panel. Everyone I have on it has at least a 60mbit connection so I know they have bandwith available under normal circumstances. Sorry for all the trouble and thanks for your assistance. You did nothing wrong in the first place. But it's pointless to continue chatting in this conversation. Instead, you should bake a cake, and here's the recipe: Restart your Emby server Start Safari at the client(must not be in the local network of Emby server, otherwise there would be no bandwidth detection) Press F12 to show the browser tools and java console Try to playback Verify that the quality setting in the Emby player is 'Auto' Stop playback Check if bandwidth detection has actually failed(look for 'VideoBitrate' and 'AudioBitrate' in the ffmpeg log, add both values to see whether it's either 1.5 or 3.0 M => that means detection failed) Copy the java console from the browser, the Emby server log and the ffmpeg log Create a new topic in the Clients >> Web App - forum with the title "Emby Web: Automatic Bandwidth detection does not work on Safari" Describe the problem Attach all logs Post 1 Link to comment Share on other sites More sharing options...
ebr 14923 Posted January 14, 2020 Share Posted January 14, 2020 When you say that there's a stable and constant environment and network connection - why not simply select e.g. 20Mbps in the client and leave it like that? That is the current answer but the problem is that Grandma doesn't know to do that. Link to comment Share on other sites More sharing options...
cptlores 23 Posted January 14, 2020 Share Posted January 14, 2020 As mentioned earlier this has changed to 3.0Mbps in the current beta cycle. https://emby.media/community/index.php?/topic/79153-force-higher-bitrates/?p=829846 That is definitely an improvement. But it is still just fixing the symptoms instead of the cause. The prober solution would of course be full blown adaptive streaming with client sending statistical data back to the server, changing bandwidth on the fly. But lacking that a simpler bandwidth ladder system would go a long way. Something like this. 1 Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted January 14, 2020 Share Posted January 14, 2020 At the same time that is above and beyond a Home user environment. Link to comment Share on other sites More sharing options...
Jdiesel 1114 Posted January 14, 2020 Share Posted January 14, 2020 (edited) How about server side control of app settings. Adjust the quality on Grandma's Roku remotely until she complains. You can also enable run away playback protection while you are at it lol Or a more comprehensive "speed test" that can be run from the app. Rather then check every single time a file is played run it once upon setup and manually thereafter. Have the client download a 50Mb dummy file from the server for a more accurate representation of bandwidth and set the quality based on that. Edited January 14, 2020 by Jdiesel Link to comment Share on other sites More sharing options...
pwhodges 1532 Posted January 14, 2020 Share Posted January 14, 2020 At the same time that is above and beyond a Home user environment. I would have thought it was just what was needed to make it work well in a home environment. Quite apart from coping with less sophisticated users (please don't focus on "granny" - I'm actually a great grandpa, and can cope just fine!), it would also help those relying on mobile Internet, whose speed can vary widely over a period, but who don't wish to be forced to set the lowest speed at all times. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 14, 2020 Share Posted January 14, 2020 (edited) that flow chart wouldn't work anyway, every Transcode at N, or Reduce to N would cause the stream to stop while ffmpeg builds a new stream. They need to look into "on-the-fly bitrate changes" I see lots of posts that say ffmpeg can not change bitrates on the fly: https://stackoverflow.com/questions/55079295/how-to-change-encoding-bitrate-adaptively-to-bandwidth-during-live-rtmp-publish And I see this ONE post that says you can, sort of maybe: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197518.html Edited January 14, 2020 by pir8radio 1 Link to comment Share on other sites More sharing options...
cptlores 23 Posted January 15, 2020 Share Posted January 15, 2020 that flow chart wouldn't work anyway, every Transcode at N, or Reduce to N would cause the stream to stop while ffmpeg builds a new stream. They need to look into "on-the-fly bitrate changes" I see lots of posts that say ffmpeg can not change bitrates on the fly: https://stackoverflow.com/questions/55079295/how-to-change-encoding-bitrate-adaptively-to-bandwidth-during-live-rtmp-publish And I see this ONE post that says you can, sort of maybe: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197518.html I agree. It is a stop gap to make the best of what is possible with the current playback scheme in Emby. But with some very minimal statistic information from the client, it would be possible to make the <Reduce N> part smarter. So that you would get only one, maybe two restarts at most. And regardless much better then the current solution (or shall we say lack of solution..). Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 15, 2020 Share Posted January 15, 2020 I think if the developers make changes to the "auto" function, to use the client side bandwidth info via the api i think that could be an excellent solution. Maybe have some specific things for the beta testers to try out.... Right now its just kind of, here is the new beta try it out, or improved video playback.. Maybe when the beta's get released give us some specific homework, I'll be glad to test the auto function across multiple devices. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted January 15, 2020 Share Posted January 15, 2020 That is the current answer but the problem is that Grandma doesn't know to do that. When she can install the app and setup the server connection, she can also make that setting. Otherwise, there would be someone who has done that for her and this one can also set the quality. I mean, that setting gets persisted and she will never need to care about it. (or are there apps where that's different)? 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