File repeats for about 1/3 in

[Gilgamesh_48 943]

Tonight I played several files through the Emby app (The beta ver) on my Roku Ultra. The first few played correctly and when they ended I was taken back to the "Next up" row where I started the show from. But when I played the last one and the credits finished running the same episode restarted at about the 1/3 point in the show. That is it behaved exactly like it simply jumped back 2/3 of the way and continued playing. There was no reload screen or buffering bar or any such indication. It just continued playing at the 1/3 point.

 

I have seen this happen before but I was not in position to capture my server log but I did this time and they are attached.

 

I am running Emby on a pretty powerful  Windows 10 PC (desktop) 

All my devices are hardwired to my network.

My media resides on a network share on a different computer.

 

I have auto play turned off

I also suppress all the home scree rows except Next up and My Media

 

As soon as I saw the restart happen I press back and the program exited and it was correctly marked as played and the next episode appeared in Next up.

 

I noticed no playback anomalies of any kind and this has happened on both transcoded and direct played content.

 

The only anomaly I see anywhere in my system is a message that the Trakt plugin failed on its attempt to sync with Trakt and a nessage from some time ago that I need to restart my server to finish updating. I do not remember if I have restarted my server today but I do not think I have,

 

The first time I saw this behavior I had a freeze playing back on my Shield and finished the playback on my Roku. The report of that is here:

https://emby.media/community/index.php?/topic/55965-wired-behavior-after-playback-failure-on-shield-involving-playback-on-roku-and-fire/

 

I was not able to capture the logs then but I have now.

 

Thanks for looking at this. I am posting it here as the Roku is the device I had the failure on but it could be some kind of server I guess.

 

Emby_server_Logs.txt

Edited February 16, 2018 by Gilgamesh_48

[vaise 304]

one of my kids reported this to me also.....  I asked them to let me know the next time so i can get logs - but you know what kids are like......

[Gilgamesh_48 943]

one of my kids reported this to me also.....  I asked them to let me know the next time so i can get logs - but you know what kids are like......

 

Indeed I do. As an avocation for 30 years I coached youth soccer, mainly girls 10-16,  and I encountered about every sort of behavior there is. However when I stopped coaching because of age I decided that the only thing wrong with youth sports in this country is the adults.

 

But thank you. I was afraid that I was the only person to see this strange behavior and it was unique to me which would mean that it probably was something about my setup which would mean that it would, probably, be a very long time before a fix was forthcoming. But with another person reporting that they have seen the same thing maybe it will be looked at quickly and fixed sooner rather than later.

[Happy2Play 8252]

Sounds like the transcoding HLS the has been there for ever.  Haven't noticed it anymore as I convert all my media to friendly mp4s.\

 

I believe this happens to all transcoded media that is played to the end.

[Gilgamesh_48 943]

Sounds like the transcoding HLS the has been there for ever.  Haven't noticed it anymore as I convert all my media to friendly mp4s.\

 

I believe this happens to all transcoded media that is played to the end.

 

That may well be the case but don't you think it should get fixed at some point if that is the cause?

 

It happened again after first restarting the server and playing I think four shows (it could have been five) that were mp4 I played an avi and the show ended and then restarted at about the 1/3 point.

 

Attached is a new set of logs The problem seems pretty easy to reproduce. 

 

BTW: Most of my library is mp4 or mkv that direct plays but my server is plenty powerful so I have not bothered to convert everything.

Emby_server_Logs_2.txt

[ebr 14904]

I believe this happens to all transcoded media that is played to the end.

 

Not really.  It only happens under specific circumstances and depends on the media being played and exactly how it is played and can also be affected by how much seeking you do or don't do during playback.

 

 

That may well be the case but don't you think it should get fixed at some point if that is the cause?

 

Hi. We actually jump through several hoops to work around this but it isn't actually our problem directly.  The only for sure fix is to force the video to transcode instead of stream copy and it isn't a consistent enough problem for us to make the decision to do that in all cases.

 

If you lower the bitrate setting in the app such that the video will fully transcode, the problem should go away.

[vaise 304]

I only had this reported recently by the kids, never before - I did turn on quicksync transcoding about 2 weeks back though - just turned that off in case it is related.

[ebr 14904]

I only had this reported recently by the kids, never before - I did turn on quicksync transcoding about 2 weeks back though - just turned that off in case it is related.

 

Yes, hardware acceleration can definitely be a factor.

[Gilgamesh_48 943]

Yes, hardware acceleration can definitely be a factor.

 

So, if I turn off hardware acceleration will I decrease the probability of the problem occurring in the future? My computer that I run Emby on is plenty powerful enough to handle my transcoding needs without hardware transcoding but I think that hardware transcoding takes some of the load off.

[Luke 37022]

Yes in your case it might make a difference because we've seen cases with quicksync encoding producing incorrect timestamps. you should be able to leave quicksync decoding on though.

[Gilgamesh_48 943]

Yes in your case it might make a difference because we've seen cases with quicksync encoding producing incorrect timestamps. you should be able to leave quicksync decoding on though.

 

Just a FWIW: Turning off hardware acceleration made no difference. But I can confirm that it is happening, it appears, on transcoded playbacks. However I also have eliminated the idea I had that it was related to the quality of the encode as I just had it happen on a pretty newly encoded MKV file that I know is at least good quality and probably very good.

 

I can deal with it but it has happened on four or five (maybe even more) different shows that have been encoded at different times using different tools and different settings. It is a bit irritating and it is frustrating to hear that the bug has been around for a while.

 

My library is quite large (in TV I have 520 shows with about 30,000 episodes) and only about 5-10% require transcoding that still would take a very long time to re-encode and really should not be needed.

 

Thank everyone for the attention to this topic but I would feel better if the responses were more "we are working on a fix" and less "we know about the problem and it has been around for a long time."

 

One more thing: I have tested and Plex does not have the bug with or without hardware transcoding turned on so it is not related to my setup or the files but rather Emby is doing, or not doing, something that Plex. does, or does not, do during playback or after playback ends.

[Luke 37022]

What did you turn off exactly? because that really should do it.

[Gilgamesh_48 943]

What did you turn off exactly? because that really should do it.

 

In settings/transcoding I turned off "Enacle hardware encoding."

 

I did not notice the "Quicksync" setting  a few lines above that but I just noticed it and realized that could be what I should have turned off. I have now turned that off (set it to none) and we will see if the problem reappears. Sorry for missing that.