simpman 6 Posted October 14, 2017 Share 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? Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted October 14, 2017 Share Posted October 14, 2017 (edited) Provide your kodi and server log. Sent from my iPhone using Tapatalk Edited October 14, 2017 by Angelblue05 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted October 14, 2017 Share Posted October 14, 2017 Also, does it do that in the webclient when you are transcoding? Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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 Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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. Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted October 14, 2017 Share 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 Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted October 14, 2017 Share Posted October 14, 2017 Interesting. You have this issue with all of your content? Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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. Link to comment Share on other sites More sharing options...
Luke 36997 Posted October 14, 2017 Share 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. Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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? Link to comment Share on other sites More sharing options...
Luke 36997 Posted October 14, 2017 Share Posted October 14, 2017 How did you add that? Link to comment Share on other sites More sharing options...
Luke 36997 Posted October 14, 2017 Share Posted October 14, 2017 MPEG-DASH support? This will not help. It will be the same actually as the techniques are very similar. Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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. Link to comment Share on other sites More sharing options...
Solution Luke 36997 Posted October 14, 2017 Solution Share Posted October 14, 2017 Wait nevermind, try disabling hardware transcoding. 1 Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share 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. Link to comment Share on other sites More sharing options...
Luke 36997 Posted October 14, 2017 Share 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 Link to comment Share on other sites More sharing options...
simpman 6 Posted October 14, 2017 Author Share Posted October 14, 2017 Thank you so much for your assistance, I will continue to investigate and hopefully find a solution. Link to comment Share on other sites More sharing options...
Recommended Posts