simpman 6 Posted October 14, 2017 Posted October 14, 2017 Affects both EmbyCon and Emby. When transcoding h256 content, when it reaches the end of the content it loops back and starts somewhere in the middle and repeats this process until it runs out of video to play. Using Emby Server 3.2.33.0, it does not affect web transcoding and haven't tried any other apps. How can I fix this?
Angelblue05 4131 Posted October 14, 2017 Posted October 14, 2017 (edited) Provide your kodi and server log. Sent from my iPhone using Tapatalk Edited October 14, 2017 by Angelblue05
Angelblue05 4131 Posted October 14, 2017 Posted October 14, 2017 Also, does it do that in the webclient when you are transcoding?
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 (edited) Thanks for the quick reply, for sure I can do that. The webclient will only play the transcoded to the end of the file and stop. It does not repeat like the kodi addons do. server.log kodi.log Edited October 14, 2017 by simpman
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 I have tried rolling back the version of the addon as well. I think the problem exists on something changed on the server end which is affecting this addon. It used to work as intended, but I can't pinpoint the exact time it stopped working. Sometime over the summer.
Angelblue05 4131 Posted October 14, 2017 Posted October 14, 2017 (edited) I cannot reproduce this. In your log, it's complaining about this CActiveAEStream::AddData - messy timestamps, increasing interval for measuring average error to 6000 ms However, I don't know if this is the error that's causing what you are seeing. I would probably try a fresh install and see if it's any better... Or ask on the official forums what this means. @@Luke Did anything change in the transcode process server-side? Log is attached above. Edited October 14, 2017 by Angelblue05
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 This was on a fresh Kodi 17.4 with just the Emby addon. The server is a fresh install on a new copy of Windows. This also affects other clients, like my Raspberry Pi. I thought the "messy timestamps" is likely due to the fact the playtime is exceeding the runtime which shouldn't happen ideally. This seems to occurs when using NVENC for hardware acceleration but not when using None, and doesn't have the same problem using the web interface regardless of HW acceleration setting. 1
Angelblue05 4131 Posted October 14, 2017 Posted October 14, 2017 Interesting. You have this issue with all of your content?
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 Just the stuff I need to transcode namely h265 10 bit mostly. My Raspberry Pi can't decode it so I use Emby to transcode and have been running into this issue lately with no obvious solution. It used to work using the HW acceleration before the summer without this issue. Sorry I can't provide better information. All non transcoded or direct played content plays as intended. If I set HW acceleration to off it transcodes as intended.
Luke 40091 Posted October 14, 2017 Posted October 14, 2017 I cannot reproduce this. In your log, it's complaining about this CActiveAEStream::AddData - messy timestamps, increasing interval for measuring average error to 6000 ms However, I don't know if this is the error that's causing what you are seeing. I would probably try a fresh install and see if it's any better... Or ask on the official forums what this means. @@Luke Did anything change in the transcode process server-side? Log is attached above. No changes, this is just the nature of HLS and hasn't come up until now. You can try adding BreakOnNonKeyFrames=true to the hls query string. That will deliver an HLS manifest that goes a little bit against HLS spec in order to produce more accurately timed segments. Doing that may resolve it but may also cause the video player to have random problems when seeking. If that happens then your options are to either not use HLS or force a full video transcode without any stream copy. When there's a full transcode we have the ability to put the keyframes in the right places. When it stream copies you are subject to the contents of the original video stream and messy videos may cause problems.
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 I tried adding BreakOnNonKeyFrames=true to my play request and it doesn't appear to fix the problem. Could a possible solution involve checking the playtime vs the runtime and forcefully closing the stream if the playtime exceeds the runtime? Is their anything planned for MPEG-DASH support, and would this help here? Also how can I tell emby to force full video transcode?
Luke 40091 Posted October 14, 2017 Posted October 14, 2017 MPEG-DASH support? This will not help. It will be the same actually as the techniques are very similar.
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 I added it to the query for transcoding in playutils playurl = ( "%s&VideoCodec=h264&AudioCodec=ac3&MaxAudioChannels=6&BreakOnNonKeyFrames=true&deviceId=%s&VideoBitrate=%s" % (playurl, deviceId, self.getBitrate()*1000)) and verified that it was passing it to the server on the log. Appears to have no change. Thanks for the info on DASH I figured as much as it has the same issue over SMB as well.
Solution Luke 40091 Posted October 14, 2017 Solution Posted October 14, 2017 Wait nevermind, try disabling hardware transcoding. 1
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 Yes absolutely it works as intended when hardware transcoding is turned off, as I mentioned above. Is that the only solution? It used to work with HW decoding some time ago.
Luke 40091 Posted October 14, 2017 Posted October 14, 2017 We're seeing the hardware encoders producing incorrect timestamps with HLS and that is why this is happening. Hopefully a newer ffmpeg build in the future will resolve this. Thanks. 1
simpman 6 Posted October 14, 2017 Author Posted October 14, 2017 Thank you so much for your assistance, I will continue to investigate and hopefully find a solution.
Recommended Posts