mattykellyuk 18 Posted December 14, 2021 Posted December 14, 2021 (edited) I am seeing a lot of of direct play errors that I didn't used to see and have an example to share. This happened last night. The server was busy encoding so using 100% of cpu, could this be a factor? A remote connection attempted to play a small file on a modern fire stick (that I know can direct play this file). It errored, saying bitrate was too high, then transcoded the file to double or more the bitrate of the file. See files attached for the mediainfo of the file, the log and a speed test I ran on the server while this error happened. I am also seeing errors where the server just says direct playback error without the explanation here that the bitrate was too high. As well as users reporting that is sometimes it takes a long time for emby to start playing a file even though the server reports it playing. The video will start but takes about 30 seconds even on small files with both the server and user on full fibre bb. I run the server on a win10 machine, to my domain using cloudfare. Any other info you need please let me know and I will keep an eye out to try and get more examples. Thanks for your time. ffmpeg-transcode-217d0aba-0b20-4dd1-ab06-0f170e6ce076_1.txt mediainfo.txt Edited December 14, 2021 by mattykellyuk
Carlo 4561 Posted December 14, 2021 Posted December 14, 2021 If the remote user had to transcode because the bitrate was exceeded that would happen for two reason. The first would be that you set a bitrate limit in Network menu or you set a bitrate limit on this specific person. I'd guess it's neither of those. What I'd bet is the user lowered the client bitrate or it's set on AUTO which doesn't always work correctly and chooses far too low of a setting. Have the user check this on his client by clicking the person icon top right then changing the settings in the Playback menu. 1
mattykellyuk 18 Posted December 14, 2021 Author Posted December 14, 2021 Hi @cayars. Thanks for the suggestion. I can confirm the user does have a limit but 7mbps where this file is about 2. There is also no restriction on the general network limit. Luckily I had a similar situation just now and a compliant user. This time on a samsung TV. I asked them to move the quality setting from auto to 60mbps. It didn't help. Any other ideas? Thanks again.
RanmaCanada 495 Posted December 15, 2021 Posted December 15, 2021 Even if they manually set the bitrate to something higher, it's possible the connection would be so bad that the server will over ride it after it determines that the connection setting is invalid. Though I can not see the usual "media exceeds bitrate" reason in your log.
Carlo 4561 Posted December 15, 2021 Posted December 15, 2021 Would need to see the log for that user from your system as it could be a different reason for the transcode. If you're not doing a conversion at the same time are you having this same problem or only with the conversion? Is this an Emby system conversion being done by Emby itself or is this being done outside Emby using handbrake or similar? Software or Hardware conversion going on in the background?
Luke 42078 Posted December 15, 2021 Posted December 15, 2021 I would also try turning off cloudfare caching and see if that helps.
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 2 hours ago, Luke said: I would also try turning off cloudfare caching and see if that helps. Thanks, is that in the rules?
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 6 hours ago, RanmaCanada said: Even if they manually set the bitrate to something higher, it's possible the connection would be so bad that the server will over ride it after it determines that the connection setting is invalid. Though I can not see the usual "media exceeds bitrate" reason in your log. I didn't think this was an option with my upload speed (above) and the knowledge of the users download speed being at least 30meg.
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 6 hours ago, cayars said: Would need to see the log for that user from your system as it could be a different reason for the transcode. If you're not doing a conversion at the same time are you having this same problem or only with the conversion? Is this an Emby system conversion being done by Emby itself or is this being done outside Emby using handbrake or similar? Software or Hardware conversion going on in the background? It's happening with or without encoding happening in handbrake using software conversion. Ok I will try to get more logs when this happens again
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 3 minutes ago, cayars said: No GPU? Hardware acceleration is turned on for emby but I use software acceleration in handbrake for higher quality
ebr 16181 Posted December 15, 2021 Posted December 15, 2021 9 hours ago, Luke said: I would also try turning off cloudfare caching and see if that helps. 7 hours ago, mattykellyuk said: Thanks, is that in the rules? Hi. Not sure what you mean by "rules" but we've had multiple instances of CF caching causing playback issues.
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 Sorry. These are the settings I can see around caching. I have turned them off and will see what happens.
Carlo 4561 Posted December 15, 2021 Posted December 15, 2021 (edited) Those rules are not correct and can get you booted. Do not let them cache your videos as it's strictly against their TOS. You need to have a bypass for video. These are setting I use and set people up with and have been working well. They need to be in this order so when entering them work bottom up or re-arrange the order once all 3 are entered. Fix/change the rules and turn them back on ASAP. domain.ext/*videos/*/* Cache Level: Bypass Enabled domain.ext/*/ Cache Level: Cache Everything, Edge Cache TTL: a month Enabled domain.ext/* Edge Cache TTL: a month If you ever need to check to see if CF is causing a problem don't touch your rules but instead turn on debug mode which bypasses their processing. Edited December 15, 2021 by cayars
horstepipe 422 Posted December 15, 2021 Posted December 15, 2021 13 minutes ago, cayars said: Those rules are not correct and can get you booted. Do not let them cache your videos as it's strictly against their TOS. You need to have a bypass for video. These are setting I use and set people up with and have been working well. They need to be in this order so when entering them work bottom up or re-arrange the order once all 3 are entered. Fix/change the rules and turn them back on ASAP. domain.ext/*video/*/* Cache Level: Bypass Enabled domain.ext/*/ Cache Level: Cache Everything, Edge Cache TTL: a month Enabled domain.ext/* Edge Cache TTL: a month If you ever need to check to see if CF is causing a problem don't touch your rules but instead turn on debug mode which bypasses their processing. are you sure it is domain.ext/*video/*/* and not domain.ext/*videos/*/* ?
Carlo 4561 Posted December 15, 2021 Posted December 15, 2021 Yes, good catch. As soon as I saw that I knew it was videos and had to check my CG rules which were fine. I must have goofed typing that. I edited my previous message!
visproduction 315 Posted December 15, 2021 Posted December 15, 2021 (edited) It may be useful, if you haven't already done this to have the friend, who is trying to watch the media, to do a speed check at similar times of the day. The in and out bandwidth with any broadband should be enough to handle media through put, but there are sometimes issues. Satellite Internet host have delivery delays, netwrok setup problems can cause lost packets. Also outbound traffic is limited by most hosts often to 6 or 10 mbps. Which should be enough to handle multiple outgoing media content, but someone locally doing a video conference or a game could cause outgoing media, maybe to have packet loss. It's probably all the other server settings or encoding issues, everyone is discussing. But, for example, a TV receiving on Wifi and a printer turned on set to broadcast between the TV and the router could cause mayube 20% packet loss and might show up as suttering on high res content. Edited December 15, 2021 by visproduction
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 (edited) 53 minutes ago, cayars said: Those rules are not correct and can get you booted. Do not let them cache your videos as it's strictly against their TOS. You need to have a bypass for video. These are setting I use and set people up with and have been working well. They need to be in this order so when entering them work bottom up or re-arrange the order once all 3 are entered. Fix/change the rules and turn them back on ASAP. domain.ext/*videos/*/* Cache Level: Bypass Enabled domain.ext/*/ Cache Level: Cache Everything, Edge Cache TTL: a month Enabled domain.ext/* Edge Cache TTL: a month If you ever need to check to see if CF is causing a problem don't touch your rules but instead turn on debug mode which bypasses their processing. Thanks very much. Is the below check? I couldn't see the 'Enabled' bit. Could this be causing my problems? Edited December 15, 2021 by mattykellyuk
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 (edited) I have just been able to replicate the problem users are experiencing on my android phone using signal not wifi. I requested to play a very small file and I got a spinning wheel. The server said nothing was happening. After about 2 minute it started to direct play. I then checked my task manager on the server in the 'Ethernet ' tab it was saying 'send 75mbps'. At the time only one person was watching something very small. I paused handbrake and after a about a minutes this 'send' went down to about 500kbps. This sounds like the it could be relate. I have since restarted handbrake and the 'send' is still normal. Could it be a Ethernet driver thing? Edited December 15, 2021 by mattykellyuk
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 (edited) Update. I have restarted the server and not restarted handbrake. Requested the server play a small file remotely (on my phone on signal), the server doesn't react for about 2 minutes, at this time the ethernet tab in task manager goes up to about 75mbps until it's starts to play when it goes down to under 1mbps Edited December 15, 2021 by mattykellyuk
ebr 16181 Posted December 15, 2021 Posted December 15, 2021 1 hour ago, mattykellyuk said: I have just been able to replicate the problem users are experiencing on my android phone using signal not wifi. I requested to play a very small file and I got a spinning wheel. The server said nothing was happening. After about 2 minute it started to direct play. This sounds exactly like the symptoms other users have reported when using CF caching. Have you disabled that?
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 2 hours ago, mattykellyuk said: Thanks very much. Is the below check? I couldn't see the 'Enabled' bit. Could this be causing my problems? These are the settings I have in CF as advised by @cayars. Anyone know if there are further cache options in CF?
Carlo 4561 Posted December 15, 2021 Posted December 15, 2021 That just means it works for me, but no guarantee it will work for you. I'm not using Cloudflare through nginx if that makes a difference to your setups. Log into CloudFlare and turn on Debug mode. Then try playing back the same media and see what happens. It's quite possible CF changed something globally or regionally that could give different results. If you get better results try test #2 by clearing/purging the cache on Cloudflare and then turning debug mode back off. Wait 5 minutes and try playing back the media again. One thing to keep in mind with any type of proxy be it software you update running in your LAN or using a service like Cloudflare. Things change that you don't know about and have to play catch up to figure it out and remedy it. Over the years we have had to update/change Cloudflare configs a number of times. Once was only a month or two ago.
mattykellyuk 18 Posted December 15, 2021 Author Posted December 15, 2021 (edited) 12 minutes ago, cayars said: That just means it works for me, but no guarantee it will work for you. I'm not using Cloudflare through nginx if that makes a difference to your setups. Log into CloudFlare and turn on Debug mode. Then try playing back the same media and see what happens. It's quite possible CF changed something globally or regionally that could give different results. If you get better results try test #2 by clearing/purging the cache on Cloudflare and then turning debug mode back off. Wait 5 minutes and try playing back the media again. One thing to keep in mind with any type of proxy be it software you update running in your LAN or using a service like Cloudflare. Things change that you don't know about and have to play catch up to figure it out and remedy it. Over the years we have had to update/change Cloudflare configs a number of times. Once was only a month or two ago. of course. I hope I didn't sound ungrateful. I appreciate your help. I can't seem to find the debug options, whereabouts is it in CF? Edit: I enabled development mode and seems better! Edited December 15, 2021 by mattykellyuk
Carlo 4561 Posted December 15, 2021 Posted December 15, 2021 OK that's good as it seems you've found the issue. Of course it may not be Cloudflare but a reverse proxy issue if you're running nginx. Running any reverse proxy? I would say the next step you want to do is compare your settings to these: If running nginx compare to these as well: Let us know if you found any differences and if so how retesting goes when you turn off debug mode. 1
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