Yet Another Skipping/rewinding movie only on Roku

[Blam84 13]

3.10 to Yuma

Roku App

Approx 4:30pm

embyserver(1).txt ffmpeg-remux-4652ca94-7035-40f4-8a41-b6928176865e_1.txt

[Luke 37250]

HI there, can you please describe the issue? Thanks.

[Blam84 13]

4 hours ago, Luke said:

HI there, can you please describe the issue? Thanks.

While watching a video, at random points in the video, it will rewind a few seconds and replay. Typically no more than 3 to 5 seconds

[ebr 14959]

12 hours ago, Blam84 said:

Typically no more than 3 to 5 seconds

I'm going to guess it is either 3 or 6 seconds as it sounds like it is repeating HLS segments.  I tried to go through your ffmpeg log and cannot see it ever going backwards (but it is long so may have missed it). 

[Blam84 13]

3 hours ago, ebr said:

I'm going to guess it is either 3 or 6 seconds as it sounds like it is repeating HLS segments.  I tried to go through your ffmpeg log and cannot see it ever going backwards (but it is long so may have missed it). 

What is the solution?

[speechles 1929]

The audio channel number isn't supported. This means the audio is being transcoded. The Roku keys video frames to sync with the audio. It isn't making the normal 3 second slices.

 

Quote

16:24:49.183 [segment @ 0000022e836bbc80] Opening 'C:\Users\%%%%%\AppData\Roaming\Emby-Server\programdata\transcoding-temp\B10ED8\B10ED8.m3u8.tmp' for writing
16:24:49.186 SegmentComplete=video:0 Index=518 Start=1554.012000 End=1556.889000 Duration=2.877000 offset_pts=0 start_pts=1554012000 Frames=72 filename=B10ED8_518.ts
16:24:49.186 [segment @ 0000022e836bbc80] Opening 'C:\Users\%%%%%\AppData\Roaming\Emby-Server\programdata\transcoding-temp\B10ED8\B10ED8_519.ts.tmp' for writing
16:24:49.222 [segment @ 0000022e836bbc80] Opening 'C:\Users\%%%%%\AppData\Roaming\Emby-Server\programdata\transcoding-temp\B10ED8\B10ED8.m3u8.tmp' for writing
16:24:49.225 SegmentComplete=video:0 Index=519 Start=1557.015000 End=1559.934000 Duration=2.919000 offset_pts=0 start_pts=1557015000 Frames=73 filename=B10ED8_519.ts

The duration is coming up short.

 

Quote

03:58:05.987 [segment @ 0000026a1fba3740] Opening 'C:\Users\speechles\AppData\Roaming\Emby-Server\programdata\transcoding-temp\D5E41C\D5E41C_11.ts.tmp' for writing

03:58:06.131 elapsed=00:00:03.01 frame= 851 fps=282 q=28.0 size=N/A time=00:00:35.16 bitrate=N/A throttle=off speed=11.7x

03:58:06.265 [segment @ 0000026a1fba3740] Opening 'C:\Users\speechles\AppData\Roaming\Emby-Server\programdata\transcoding-temp\D5E41C\D5E41C.m3u8.tmp' for writing

03:58:06.269 SegmentComplete=video:0 Index=11 Start=33.033000 End=36.036000 Duration=3.003000 offset_pts=0 start_pts=33033000 Frames=72 filename=D5E41C_11.ts

03:58:06.269 [segment @ 0000026a1fba3740] Opening 'C:\Users\speechles\AppData\Roaming\Emby-Server\programdata\transcoding-temp\D5E41C\D5E41C_12.ts.tmp' for writing

03:58:06.545 [segment @ 0000026a1fba3740] Opening 'C:\Users\speechles\AppData\Roaming\Emby-Server\programdata\transcoding-temp\D5E41C\D5E41C.m3u8.tmp' for writing

03:58:06.548 SegmentComplete=video:0 Index=12 Start=36.036000 End=39.039000 Duration=3.003000 offset_pts=0 start_pts=36036000 Frames=72 filename=D5E41C_12.ts

 

Here is what a normal transcode duration should be.

 

The Roku is having problem stitching them together for some reason. Almost like the timestamps go back into the previously fetched section for the just fetched section.

 

If you run this through MKVToolNix GUI and just "start remux" and let it complete does the newly remuxed file have the same problems?

If it is a problem with the header or something odd remuxing it should take care of it. Unless it is something they've encoded into the stream. That is the problem with these types of media from that particular release group. Anyone in their group can encode and they don't really have standards. This isn't a "scene" release which has standards. You may have to correct the problems the media has, such as bad headers, multiple default streams set, etc. The Roku is very strict about adhering to standards. Let us know if remuxing solves the problem.

 

NOTE: You can also add a second AAC track in stereo and it will direct play and avoid the problem altogether. You would have to rip the track out, convert with ffmpeg or similar, then stick it back in with MKVToolNix.

Edited May 6 by speechles

[pwhodges 1539]

I was actually reading this when my wife called me to watch TV with her - on our Roku TV.  We started playing The Piano (an off-air recording), and quite early in it the picture froze briefly, followed by a number of stutters which looked like mis-ordered blocks; then it settled down, but the subs were out of sync (a skip back 10s and forward again fixed the subs timing).  This has never happened before that I recall. 

Roku fw version 12.5.5 (updated 3 days ago?).

Logs below.

Paul

Roku glitches .zip

[speechles 1929]

@pwhodges

Quote

21:27:00.179 [mpeg2video @ 000001eb7ccb6340] Invalid frame dimensions 0x0.
    Last message repeated 8 times
21:27:00.184 [mpegts @ 000001eb7c82de80] start time for stream 2 is not set in estimate_timings_from_pts
21:27:00.184 [mpegts @ 000001eb7c82de80] start time for stream 3 is not set in estimate_timings_from_pts
21:27:00.184 [mpegts @ 000001eb7c82de80] PES packet size mismatch
21:27:00.184 [mpegts @ 000001eb7c82de80] Packet corrupt (stream = 1, dts = 2958882990).
21:27:00.184 [mpegts @ 000001eb7c82de80] PES packet size mismatch
21:27:00.184 [mpegts @ 000001eb7c82de80] Packet corrupt (stream = 2, dts = 2958874350).
21:27:00.184 [mpegts @ 000001eb7c82de80] stream 2 : no TS found at start of file, duration not set

Because this is a TS file it is common it will lack some of these details. Such as the invalid frame dimensions is normal. That is okay. But the rest of them below are not usual. The PES packet size mismatch is normal see that often and no problems arise. But the packet corrupt parts are not normal. The duration isn't set on the audio track because of a lack of timestamping. This will definitely cause a problem on the Roku.

Can you try to repackage this as an MKV with MKVToolNix GUI? Once it is converted to MKV the container can direct play on the Roku. Once you enable subtitles with the MKV it should actually transcode the DVDSUB into the video stream without those problems encountered in the TS stream. All streams should copy into the new MKV container without modification. You just need to remux into MKV and group this with the TS file on Emby creating two versions. Having both the TS and MKV available you can compare playback. The MKV version should act superior in every way, at least on the Roku.

Edited May 7 by speechles