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 37315]

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 14969]

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 1542]

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

[Blam84 13]

On 5/6/2024 at 1:50 PM, speechles said:

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.

 

The duration is coming up short.

 

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.

Circling back to this. I can say with confidence that this happens with the majority of the files that I have. You're saying that this is a problem with Roku, and yet I ran Plex on Roku for years and had none of these issues. So it seems to me that Emby is the problem. And even if repackaging this solves the issue, I'm not going to repackage all of my files. 

So out of curiosity, is this something you all are actually going to troubleshoot? Or is this something I just need to decide to live with or not? Because it happens with nearly every single file, and predictably happens almost 100% of the time after I pause and then begin playing again.

[speechles 1929]

1 hour ago, Blam84 said:

Circling back to this. I can say with confidence that this happens with the majority of the files that I have. You're saying that this is a problem with Roku, and yet I ran Plex on Roku for years and had none of these issues. So it seems to me that Emby is the problem. And even if repackaging this solves the issue, I'm not going to repackage all of my files. 

So out of curiosity, is this something you all are actually going to troubleshoot? Or is this something I just need to decide to live with or not? Because it happens with nearly every single file, and predictably happens almost 100% of the time after I pause and then begin playing again.

 

Apologies. What I meant is it isn't anything wrong with the Emby Roku app. It has to do with the ffmpeg packaged with Emby.

What I have suggested to you are just ways to work-around this problem until a proper solution is found and this can be resolved. It is something incorrect with the transcoding happening. I was suggesting ways to make your media have more Direct Play which would avoid the problem of transcoding altogether. I wasn't expecting you to convert your entire library. That would be a huge burden. I just wanted to confirm that it would fix the issue.

I would also like others to know who might reading this thread that transcoding is to be avoided, not encouraged. This is why the issue is important to fix and we are not going to just avoid this thread. You are not going to have to live with it.

Since this is out of my wheel house and for the issue to get fixed by the right people they need to be involved. I can try to push this higher up in priority by mention @Lukeand @softworkzin this thread. They would have more intimate knowledge about the ffmpeg packaged with Emby and how this issue might get corrected.

Edited Tuesday at 02:24 AM by speechles

[Blam84 13]

9 hours ago, speechles said:

 

Apologies. What I meant is it isn't anything wrong with the Emby Roku app. It has to do with the ffmpeg packaged with Emby.

What I have suggested to you are just ways to work-around this problem until a proper solution is found and this can be resolved. It is something incorrect with the transcoding happening. I was suggesting ways to make your media have more Direct Play which would avoid the problem of transcoding altogether. I wasn't expecting you to convert your entire library. That would be a huge burden. I just wanted to confirm that it would fix the issue.

I would also like others to know who might reading this thread that transcoding is to be avoided, not encouraged. This is why the issue is important to fix and we are not going to just avoid this thread. You are not going to have to live with it.

Since this is out of my wheel house and for the issue to get fixed by the right people they need to be involved. I can try to push this higher up in priority by mention @Lukeand @softworkzin this thread. They would have more intimate knowledge about the ffmpeg packaged with Emby and how this issue might get corrected.

Got it. Thanks so much for the detailed reply and for explaining everything thoroughly. While you all work on things, can you give me some suggestions for how I can avoid this moving forward? Different file types to look for, or other things I can adjust?

[speechles 1929]

13 hours ago, Blam84 said:

Got it. Thanks so much for the detailed reply and for explaining everything thoroughly. While you all work on things, can you give me some suggestions for how I can avoid this moving forward? Different file types to look for, or other things I can adjust?

If at all possible avoid using TS container on the Roku. Because a direct played TS stream is seen as a live stream. It will not allow fast-forward or scrubbing. Because of this Emby will transcode the container to an m3u8 to the Roku.

Instead you can manually remux the TS stream into an MKV and you have a much better chance for Direct Play.

The DVDSUB/PGSSUB image based subtitles will force a transcode of the video stream on the Roku. Because these are image based and the Roku does not support it these will cause video transcoding.

The Roku behaves best with the MKV container. If you need subtitles obtain text-based SRT using the available Emby plugins. These will be placed alongside your media and fetched with a scheduled task. Then you are sure that you are able to play your media in the best way possible on your Roku.

Edited Wednesday at 01:08 AM by speechles

[softworkz 3350]

4 minutes ago, speechles said:

If at all possible avoid using TS container on the Roku. Because a direct played TS stream is seen as a live stream. It will not allow fast-forward or scrubbing. These must be transcode and sent to the Roku. Instead remux the TS stream into an MKV and you have a much better chance for Direct Play. The DVDSUB/PGSSUB image based subtitles will force a transcode of the video stream on the Roku. Because these are image based and the Roku does not support it these will cause video transcoding.

TS streams cannot have DVD nor PGS subtitles, only DVBSub (image) or Teletext (text), so you must be talking about two separate things. 

TS streams should never be direct played, I don't understand why tihs is even enabled for the Roku, there must be something wrong with the device profile. Those streams should always be streamed via HLS, in which case there is still a chance that it doesn't need to be transcoded (only segmented by ffmpeg), but pure TS streams are not suitable in any way for directplay  - not on any device actually, it's just that some do better and some do worse in handling that format, which is just defned as a stream but not as a contaienr format for file storage.

[Blam84 13]

4 minutes ago, softworkz said:

TS streams cannot have DVD nor PGS subtitles, only DVBSub (image) or Teletext (text), so you must be talking about two separate things. 

TS streams should never be direct played, I don't understand why tihs is even enabled for the Roku, there must be something wrong with the device profile. Those streams should always be streamed via HLS, in which case there is still a chance that it doesn't need to be transcoded (only segmented by ffmpeg), but pure TS streams are not suitable in any way for directplay  - not on any device actually, it's just that some do better and some do worse in handling that format, which is just defned as a stream but not as a contaienr format for file storage.

ELI5 what I can do about any of this?

[speechles 1929]

55 minutes ago, softworkz said:

TS streams should never be direct played, I don't understand why tihs is even enabled for the Roku

People disable the transcoding and then claim TS is supported for direct play. Or that Roku Media Player can direct play it. It is direct playable on the Roku but you cannot seek forward. When TS is direct played the Roku can only pause into a buffer and then rewind into said buffer.

This is nowhere near the same as direct seekable playback. There is a few cases of people disabling transcoding because they feel we shouldn't be transcoding things. In the case of TS streams we do it for a very good reason.

  

55 minutes ago, softworkz said:

TS streams cannot have DVD nor PGS subtitles, only DVBSub (image) or Teletext (text), so you must be talking about two separate things.

Indeed. It was an MKV to begin with. Because DVDSUB/PGSSUB are not supported on Roku it must use TS to burn in the video. This is produce misaligned segments that are too short.

I didn't mention them inside any specific container since the ROku does not support them in any container.

@softworkzThe normal 3 second segments are coming up short. Do you know the reason for that? That is the cause of this issue.

Spoiler

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

 

Edited Wednesday at 02:14 AM by speechles

[softworkz 3350]

On 5/6/2024 at 11:38 PM, pwhodges said:

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.

All of your logs are showing subtitle burn-in. It's impossible that subtitle have been delayed once and recovered or changed in any way after playing the same part again. 

Edited Wednesday at 02:17 AM by softworkz

[Luke 37315]

On 5/5/2024 at 4:33 PM, Blam84 said:

3.10 to Yuma

Roku App

Approx 4:30pm

embyserver(1).txt 3.49 MB · 2 downloads ffmpeg-remux-4652ca94-7035-40f4-8a41-b6928176865e_1.txt 989.32 kB · 7 downloads

Also as a test, if you use the playback correction function in the app, does the issue happen then?

[Blam84 13]

21 minutes ago, Luke said:

Also as a test, if you use the playback correction function in the app, does the issue happen then?

Whenever I notice this issue, I do attempt playback correction, and it resolves. However, if I pause at any point in the future, it happens again almost like clockwork. My bigger issue is that it happens with nearly every piece of media I have, so it's not an isolated incident with one or two things that I can resolve. It's every single time I watch anything.

[softworkz 3350]

How often did it happen during watching 3-10 to Yuma? Only once at 4:30?

[softworkz 3350]

And did you make a pause before? Does it always happen when you made a pause before?

[Blam84 13]

6 hours ago, softworkz said:

And did you make a pause before? Does it always happen when you made a pause before?

I honestly don't remember how many times it happened when I watch that particular movie. But I can tell you what happens repeatedly with plenty of my files. It happens without pausing regularly. But when I do pause, 99% of the time I will experience this issue.

[Blam84 13]

On 5/22/2024 at 7:07 AM, Blam84 said:

I honestly don't remember how many times it happened when I watch that particular movie. But I can tell you what happens repeatedly with plenty of my files. It happens without pausing regularly. But when I do pause, 99% of the time I will experience this issue.

It just happened again with a different file. About 5 minutes after pausing. Here's what was listed in the stats for nerds: 

Stream: MP4 (2.22Mbs) -> Direct play 

Video: 1080HEVC -> Direct Play (2Mbs) dropped frames 60

Audio: English AAC 5.1 Default -> Transcode (AC3 5.1 224 kbps)

[ebr 14969]

Okay, so likely related to stream copying HEVC.