MPEG2 transcoding instead of direct play (AVCHD is OK)

[unisoft 272]

Hello

 

I have the ROKU Streaming Stick on v9.0 (latest) and on latest Emby version and Synology NAS on Latest released Emby 4.0.0.2.

 

Two issues - both are MPEG2 playback of videos.

 

Issue 1: Live TV playback of MPEG2 channels in SD:

 

MPEG4 HD Live TV is fine and no transcode.

 

MPEG2 SD channels transcode despite the ROKU stick supporting MPEG2 now.

 

I use HD Homerun quad tuner on gigabit network (not ISP dumb router or cheap switch).

 

Here is the paste of the log from server - it complains about Container not supported?

 

2019-03-02 11:31:20.080 Info HttpServer: HTTP GET http://192.168.1.35:8096/emby/videos/114492/live.m3u8?DeviceId=cbdd50d2-42f7-55d4-9c62-a49d9de14b8a&MediaSourceId=native_2c256c4a8b11c6b79d8ea2a3022429e8_9ff54b38d97b2330ff869fc5546747ae&VideoCodec=h264,mpeg1video,mpeg2video,hevc&AudioCodec=aac,mp2,mp3,flac,opus,vorbis,lpcm&VideoBitrate=79872000&AudioBitrate=128000&MaxFramerate=61&MaxWidth=3840&MaxHeight=2160&PlaySessionId=6f8b882558ad4654ab26603633bcd948&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_2c256c4a8b11c6b79d8ea2a3022429e8_9ff54b38d97b2330ff869fc5546747ae&AudioStreamIndex=-1&TranscodingMaxAudioChannels=2&SegmentContainer=ts&SegmentLength=3&MinSegments=1&BreakOnNonKeyFrames=True&h264-maxrefframes=16&h264-videobitdepth=8&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&aac-audiochannels=2&flac-audiochannels=2&lpcm-audiochannels=2&mp3-audiochannels=2&mp2-audiochannels=2&vorbis-audiochannels=2&opus-audiochannels=2&TranscodeReasons=ContainerNotSupported. Host=192.168.1.35:8096, User-Agent=Roku/DVP-9.0 (509.00E04142A), Accept=*/*, Accept-Encoding=deflate, gzip
2019-03-02 11:31:20.083 Info HttpServer: HTTP Response 200 to 192.168.1.88. Time: 3ms. http://192.168.1.35:8096/emby/videos/114492/live.m3u8?DeviceId=cbdd50d2-42f7-55d4-9c62-a49d9de14b8a&MediaSourceId=native_2c256c4a8b11c6b79d8ea2a3022429e8_9ff54b38d97b2330ff869fc5546747ae&VideoCodec=h264,mpeg1video,mpeg2video,hevc&AudioCodec=aac,mp2,mp3,flac,opus,vorbis,lpcm&VideoBitrate=79872000&AudioBitrate=128000&MaxFramerate=61&MaxWidth=3840&MaxHeight=2160&PlaySessionId=6f8b882558ad4654ab26603633bcd948&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_2c256c4a8b11c6b79d8ea2a3022429e8_9ff54b38d97b2330ff869fc5546747ae&AudioStreamIndex=-1&TranscodingMaxAudioChannels=2&SegmentContainer=ts&SegmentLength=3&MinSegments=1&BreakOnNonKeyFrames=True&h264-maxrefframes=16&h264-videobitdepth=8&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&aac-audiochannels=2&flac-audiochannels=2&lpcm-audiochannels=2&mp3-audiochannels=2&mp2-audiochannels=2&vorbis-audiochannels=2&opus-audiochannels=2&TranscodeReasons=ContainerNotSupported

 

Issue 2: Playback of MPEG2 file content (SD) .TS:

 

Also, MPEG2 .TS files sit at "Retrieving" progress bar. I'm sure this played fine in previous versions of Emby and they play fine on Samsung and LG apps. I don't get what "No direct play profiles found for Path" means in log below as set to "AUTO" for playback.

 

here is log of that

2019-03-02 10:59:49.356 Info HttpServer: HTTP Response 204 to 192.168.1.88. Time: 16ms. http://192.168.1.35:8096/emby/Sessions/Capabilities/Full
2019-03-02 10:59:49.372 Info HttpServer: HTTP POST http://192.168.1.35:8096/emby/Items/107439/PlaybackInfo?UserId=29a3f9eb612d49beb0f5b566bd9c39ba&maxstreamingbitrate=80000000&starttimeticks=00000000. UserAgent: Roku/DVP-9.0 (509.00E04142A)
2019-03-02 10:59:49.596 Info App: User policy for LAN. EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
2019-03-02 10:59:49.614 Info App: Profile: Roku SG, Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2019-03-02 10:59:49.632 Info App: Profile: Roku SG, No direct play profiles found for Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts
2019-03-02 10:59:49.664 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.1.88, IsInLocalNetwork: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, No direct play profiles found for Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts
2019-03-02 10:59:49.664 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.1.88, IsInLocalNetwork: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, No direct play profiles found for Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts
2019-03-02 10:59:49.688 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.1.88, IsInLocalNetwork: True
2019-03-02 10:59:49.716 Info HttpServer: HTTP Response 200 to 192.168.1.88. Time: 344ms. http://192.168.1.35:8096/emby/Items/107439/PlaybackInfo?UserId=29a3f9eb612d49beb0f5b566bd9c39ba&maxstreamingbitrate=80000000&starttimeticks=00000000
2019-03-02 10:59:49.759 Info HttpServer: HTTP GET http://192.168.1.35:8096/emby/Items/107429/Images/Primary?maxHeight=350&tag=f9de3fdb742383f74dd8813c5dde7c89&EnableImageEnhancers=false. UserAgent: Roku/DVP-9.0 (509.00E04142A)
2019-03-02 10:59:49.769 Info HttpServer: HTTP Response 200 to 192.168.1.88. Time: 10ms. http://192.168.1.35:8096/emby/Items/107429/Images/Primary?maxHeight=350&tag=f9de3fdb742383f74dd8813c5dde7c89&EnableImageEnhancers=false
2019-03-02 10:59:49.781 Info HttpServer: HTTP GET http://192.168.1.35:8096/emby/Videos/107439/index.bif?width=320&mediaSourceId=aeed9aaf9a7d609e9fb06d801bfc914a. Connection=close, Host=192.168.1.35:8096, User-Agent=Roku/DVP-9.0 (509.00E04142A)
2019-03-02 10:59:49.782 Error HttpServer: Could not find handler for /emby/Videos/107439/index.bif
2019-03-02 10:59:49.789 Info HttpServer: HTTP GET http://192.168.1.35:8096/emby/videos/107439/master.m3u8?DeviceId=cbdd50d2-42f7-55d4-9c62-a49d9de14b8a&MediaSourceId=aeed9aaf9a7d609e9fb06d801bfc914a&VideoCodec=h264,mpeg1video,mpeg2video,hevc&AudioCodec=aac,mp2,mp3,flac,opus,vorbis,lpcm&VideoBitrate=79808000&AudioBitrate=192000&MaxFramerate=61&MaxWidth=3840&MaxHeight=2160&PlaySessionId=06f31b5de8014e2cbf22ca1c273d282c&AudioStreamIndex=2&TranscodingMaxAudioChannels=2&SegmentContainer=ts&SegmentLength=3&MinSegments=1&BreakOnNonKeyFrames=True&h264-maxrefframes=16&h264-videobitdepth=8&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&aac-audiochannels=2&flac-audiochannels=2&lpcm-audiochannels=2&mp3-audiochannels=2&mp2-audiochannels=2&vorbis-audiochannels=2&opus-audiochannels=2&TranscodeReasons=ContainerNotSupported. Host=192.168.1.35:8096, User-

 

[ebr 14903]

Hi.  Please attach the ffmpeg log from that playback.

 

Thanks.

[unisoft 272]

Hi.  Please attach the ffmpeg log from that playback.

 

Thanks.

 

It created TWO logs for playback of the media MPEG2 SD file (these files ahve played for years on virtually any other player like Windows Media Center, LG and Samsung Emby app, Media Player, VLC, MAC Media apps).

 

I attach the text logs. They are MPEG2 720x576 PAL, Anamorphic flag for 16:9 on 4:3 content, and Dolby Digital (AC3) - (DVD source content).

 

thanks

ffmpeg1.txt

ffmpeg2.txt

Edited March 2, 2019 by unisoft

[speechles 1917]

[mpegts @ 0xe89e40] Could not detect TS packet size, defaulting to non-FEC/DVHS
[mpegts @ 0xe89e40] PES packet size mismatch
    Last message repeated 495 times
[mpegts @ 0xe89e40] probed stream 0 failed
[mpegts @ 0xe89e40] nothing to probe for stream 1
[mpegts @ 0xe89e40] probed stream 1 failed
[mpegts @ 0xe89e40] probed stream 2 failed
[mpegts @ 0xe89e40] probed stream 3 failed

The Roku cannot direct play TS files and allow seeking. To give you the ability to seek TS streams we must transcode them. This should show as DirectStream in the Stats-for-Nerds of the app. DirectStream will copy both the video and audio stream. If the audio is not supported it will Remux. Remux is directly copied video stream and transcoded audio stream.

 

The reason your file does not play on Roku is because the header is corrupted. Ffmpeg cannot find streams inside the TS file to play. This causes ffmpeg to stall and hang. The Roku app will hang for a bit but should timeout and error eventually. When the Roku app errors it will tell the server to kill the stalled ffmpeg process.

 

Are you sure this file plays on other Emby apps?

 

You might be able to use MKVToolNix GUI (drag 'n drop) to convert the TS into MKV. The Roku will play MKV with MPEG2/AC3 directly no problem. If you can get the streams out of that TS which might be possible with MKVToolNix.

Edited March 2, 2019 by speechles

[unisoft 272]

[mpegts @ 0xe89e40] Could not detect TS packet size, defaulting to non-FEC/DVHS
[mpegts @ 0xe89e40] PES packet size mismatch
    Last message repeated 495 times
[mpegts @ 0xe89e40] probed stream 0 failed
[mpegts @ 0xe89e40] nothing to probe for stream 1
[mpegts @ 0xe89e40] probed stream 1 failed
[mpegts @ 0xe89e40] probed stream 2 failed
[mpegts @ 0xe89e40] probed stream 3 failed

The Roku cannot direct play TS files and allow seeking. To give you the ability to seek TS streams we must transcode them. This should show as DirectStream in the Stats-for-Nerds of the app. DirectStream will copy both the video and audio stream. If the audio is not supported it will Remux. Remux is directly copied video stream and transcoded audio stream.

 

The reason your file does not play on Roku is because the header is corrupted. Ffmpeg cannot find streams inside the TS file to play. This causes ffmpeg to stall and hang. The Roku app will hang for a bit but should timeout and error eventually. When the Roku app errors it will tell the server to kill the stalled ffmpeg process.

 

Are you sure this file plays on other Emby apps?

 

You might be able to use MKVToolNix GUI (drag 'n drop) to convert the TS into MKV. The Roku will play MKV with MPEG2/AC3 directly no problem. If you can get the streams out of that TS which might be possible with MKVToolNix.

 

 

Hi, yes I have around 1000 MPEG2 files at least and they all give them the same result BUT only on Roku. All other players and the LG App and Samsung Emby app play them fine (direct).

[speechles 1917]

Any app that has to transcode these will run into the same problem. Are you using a custom ffmpeg? Is there something different about your OS install?

 

It is related to transcoding and being able to probe the file that causes Roku to fail. It isn't anything the Roku is doing or that we are doing in the Roku app. The Roku is the end device experiencing the issue but isn't the root cause. The cause is happening when the Roku tells the Emby server that it does not support the TS container. This involves ffmpeg and hls streaming. That means it is something larger causing your issue within ffmpeg or your files themselves.

[unisoft 272]

Any app that has to transcode these will run into the same problem. Are you using a custom ffmpeg? Is there something different about your OS install?

 

It is related to transcoding and being able to probe the file that causes Roku to fail. It isn't anything the Roku is doing or that we are doing in the Roku app. The Roku is the end device experiencing the issue but isn't the root cause. The cause is happening when the Roku tells the Emby server that it does not support the TS container. This involves ffmpeg and hls streaming. That means it is something larger causing your issue within ffmpeg or your files themselves.

 

Those videos have been ripped (sometimes recoded) from Windows 7, Windows 8.1 and Windows 10 (various versions) over the years using DVD Shrink (without re-encoding to extract the initial DVD with AnyDVD) and sometimes using paid for TPMGEnc editing products where some were recoded. They conform to UK PAL broadcast standards - in fact they are usually a copy from the DVD as coded. I've never had an issue in any player before.

 

If I rename them to ".mpg" they play direct fine on Roku Emby. In older versions of the ROKU OS, they were renamed to .TS as .TS is technically the right extension for MPEG2 and MPG is really meant for MPEG1. I'm sure I renamed them because it didn't like .mpg in the Emby Roku version at the time.

 

So if they are corrupt (and I haven't got 1000, I have 1000's), the question is why a simple extension rename makes them work fine again? The correct extension though is .TS - this should still work in Roku like all the other players (even Emby ones like LG and Samsung play them as .TS fine).

 

I can't use MKV as I reserve MKV for 24p files so that Media Browser 2.6.2 can switch to a different player based on file extension, so that 24hz switching happens on the computer graphics card that normally runs at PAL 50hz. At the moment I need to keep backwards compatibility with MB 2.6.2 as well. Again MB 2.6.2 doesn't have an issue with .TS or .mpg. It just plays them.

Edited March 2, 2019 by unisoft

[speechles 1917]

I did not say your files were corrupt. I said that ffmpeg could not read the header which implies your ffmpeg is wrong or the files were.

 

When you change extension/container(by simply rename the extension) it changes how the app will see the header constructed. It isn't something you should do as most media players do not probe the file. They try to follow the rules the extension has told them to acquire the header. The header tells how to decompose the container so you can consume the streams inside.

 

The files are not corrupt. Ffmpeg merely acts like they are because it doesn't understand the header of the file because the extension was changed. The moment you change the extension back to what it really should be all the problems should disappear.

 

MB 2.6.2 doesn't have an issue with the files because it isn't server/client it is just server+client in one. In this way it can direct play the file and know the right extension even though you lie to it. This can work since Windows would be fixing the mistake.

Edited March 2, 2019 by speechles

[unisoft 272]

I did not say your files were corrupt. I said that ffmpeg could not read the header which implies your ffmpeg is wrong or the files were.

 

When you change extension/container(by simply rename the extension) it changes how the app will see the header constructed. It isn't something you should do as most media players do not probe the file. They try to follow the rules the extension has told them to acquire the header. The header tells how to decompose the container so you can consume the streams inside.

 

The files are not corrupt. Ffmpeg merely acts like they are because it doesn't understand the header of the file because the extension was changed. The moment you change the extension back to what it really should be all the problems should disappear.

 

MB 2.6.2 doesn't have an issue with the files because it isn't server/client it is just server+client in one. In this way it can direct play the file and know the right extension even though you lie to it. This can work since Windows would be fixing the mistake.

 

I'm not sure what you mean by FFMPEG could possibly be wrong. On my Synology it would have been installed by Emby 3.x then upgrade to v4.x? I haven't got any other aps installed other than Synology's OS and Emby.

 

Should they be renamed back to .mpg then from .TS (even though that's really intended for mp1)?

 

Versions found in Emby log file:

 

ffmpeg version 4.0.2-emby_2018_12_09-20181219T192320UTC Copyright © 2000-2018 the FFmpeg developers

built with gcc 7.3.0 (GCC)

configuration: --prefix=/var/packages/EmbyServer/target/ffmpeg --enable-cross-compile --cross-prefix=x86_64-syno-linux-gnu- --target-os=linux --disable-rpath --enable-pthreads --arch=x86_64 --enable-libzimg --enable-libmfx --enable-vaapi --enable-x86asm --enable-gpl --enable-shared --disable-static --disable-debug --disable-ffplay --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --enable-gnutls --enable-libass --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libfreetype --enable-fontconfig --enable-gray --enable-libfribidi --enable-libvidstab --enable-libzvbi --disable-indev=sndio --disable-outdev=sndio --extra-version=20181219T192320UTC --extra-libs='-luuid -lstdc++'

libavutil      56. 14.100 / 56. 14.100

libavcodec     58. 18.100 / 58. 18.100

libavformat    58. 12.100 / 58. 12.100

libavdevice    58.  3.100 / 58.  3.100

libavfilter     7. 16.100 /  7. 16.100

libswscale      5.  1.100 /  5.  1.100

libswresample   3.  1.100 /  3.  1.100

libpostproc    55.  1.100 / 55.  1.100

Edited March 2, 2019 by unisoft

[Luke 37007]

Those example logs are not full transcodes anyway, the video is being stream copied into a new container.

 

Have you checked out our media conversion feature? It can help you pre-convert your files into more streaming friendly formats.

[unisoft 272]

Those example logs are not full transcodes anyway, the video is being stream copied into a new container.

 

Have you checked out our media conversion feature? It can help you pre-convert your files into more streaming friendly formats.

 

Thanks but have several TB of MPEG2. I have renamed using a utility all back to .MPG and they are playing fine now on Android, LG App, Samsung and Roku and of course MB 2.6.2 on Windows Media Center.

 

I renamed them originally because of issues, and I am sure it was the ROKU version at the time when the ROKU OS was 8.x (now 9.0.0). As I said technically MPEG2 is .TS not .mpg. MPEG2 is still the most widely used codec due to broadcast and DVD even though I know H264/H265 formats are more efficient. H265 isn't intended for interlaced SD formats though and MPEG2 is easier to edit with and do smart rendering without re-encoding and only at edit points.

Edited March 3, 2019 by unisoft

[Luke 37007]

So they are originally mpg files? Whatever they were originally, that is how i would keep them.

[unisoft 272]

So they are originally mpg files? Whatever they were originally, that is how i would keep them.

 

Sort of. I chose them to be that file extension originally, but natively they would have been MPEG2 rips using DVD Shrink without re-encode and AnyDVD of DVD VOB files (combined where multiple VOBS exist).

 

VideoREDO 4 (paid for commercial product) then does a "Quickstream" fix to correct any timing errors so the MPEG2 file is seek-able during FF and RW as often a RIP won't do this on its own.

 

The others that are a recode (because of edits) would have been done in a TMPGENC (paid for commerical) editing product that smart renders and re-codes where necessary to PAL standards for UK (720x576 25 frames interlaced usually)

 

Both products are proper commerical apps.

Edited March 4, 2019 by unisoft

[unisoft 272]

So they are originally mpg files? Whatever they were originally, that is how i would keep them.

 

RIGHT got to the bottom of it all.

 

Basically FFMPEG is being STRICT on headers. If it IS a ".TS" file extension then it expects the file to conform 100% to TRANSPORT STREAM header rules.

 

VideoRedo was likely doing a MPEG PROGRAM STREAM when .mpg was corrected originally.

 

I changed to Quicksteam fix in VideoREDO to .TS TRANSPORT STREAM and the resulting file (which is bigger) then plays fine on ROKU as a ".TS" file extension.

 

CONCLUSION: The media players auto compensated transparently for MPG or TS on playback regardless of what the file actually was. FFMPEG is being strict when consulting headers hence failure as the files not Transport headers. I think a note should go in the WIKI under file formats to state FFMPEG is strict on file type under extensions like .TS?

 

Happy now. At least I know the reason and thanks @@speechles too. 

Edited March 4, 2019 by unisoft

[Luke 37007]

Thanks for the feedback.

[Starlionblue 80]

So what can I do to make these files play direct? Use the media conversion feature on all of them?

 

(Bought a Roku last week.)

Edited May 8, 2019 by Starlionblue

[speechles 1917]

So what can I do to make these files play direct? Use the media conversion feature on all of them?

 

(Bought a Roku last week.)

 

Get MKVToolNix GUI. Then drag and drop your files onto the right hand side of the GUI. In the bottom make sure all streams are checked to copy. Hit the "Start Remux" button. It should take a few seconds. As MKV these can play back just fine. It is only when these are TS in direct play that the Roku assumes these are live streams and does not allow seeking. It thinks this is linear TV and you just get a pause button. To allow seeking we must repackage these into HLS/m3u8 and create TS slices. HLS can seek. TS directly cannot. MKV can always seek. MKV is your best friend.

Edited May 8, 2019 by speechles

[Luke 37007]

Yes I would suggest using our media conversion feature.

[Starlionblue 80]

Thx for the replies.

 

I pointed the conversion features at a few files and it worked fine. Roku plays the converted files without transcoding.

 

Trying MKVToolNix GUI but it can only do one file at a time I think.

 

 I'll try to script with MKVMerge so I can do batches but I need coffee first. Any hints appreciated. 

Edited May 8, 2019 by Starlionblue

[Starlionblue 80]

Ha. After an hour of fiddling with command line MKVMerge without success I found the "Actions for all Tabs" menu in MKVToolNix. 

[Starlionblue 80]

Get MKVToolNix GUI. Then drag and drop your files onto the right hand side of the GUI. In the bottom make sure all streams are checked to copy. Hit the "Start Remux" button. It should take a few seconds. As MKV these can play back just fine. It is only when these are TS in direct play that the Roku assumes these are live streams and does not allow seeking. It thinks this is linear TV and you just get a pause button. To allow seeking we must repackage these into HLS/m3u8 and create TS slices. HLS can seek. TS directly cannot. MKV can always seek. MKV is your best friend.

 

Hi again. I tried the MKVTooNix GUI. The files convert fine and I can play them in Windows or in the Emby web interface. However when playing on the Roku they are stuck in the middle of "Retrieving". At the same time, the server interface shows them as playing with directly with no transcoding.

 

Files converted with Emby work fine.

 

Server log is here.

[Luke 37007]

Sounds like it is muxing them in a way that the Roku player can't handle. Transcoding would clean that up although that would defeat what you're trying to accomplish.

[Starlionblue 80]

Looks like it. I’ll try to find another muxing tool. Time to give ffmpeg a try. Much more horsepower in my PC than my QNAP so things go way faster.

 

Btw how is it that files converted by Emby Server are much smaller than the originals?

[Starlionblue 80]

I’ll add that trying to play these files locks Emby for Roku up completely. You can’t use Stop or Back at all. You either have to go to Home on the Roku or stop playback from Emby Server.

[speechles 1917]

I’ll add that trying to play these files locks Emby for Roku up completely. You can’t use Stop or Back at all. You either have to go to Home on the Roku or stop playback from Emby Server.

 

Weird. That isn't supposed to happen unless you put some codec inside an MKV that doesn't really belong there. Our detection is supposed to catch these mistakes but some of that detection depends on the Roku itself throwing an error and letting us do some playback recovery. When it doesn't do that and just hangs we presently have no timers set to catch when the Roku video player goes rogue and just decides to hang. Eventually we will get to adding timers to the video player event when there is buffering. These timers can catch these conditions and gracefully get us the "F" out of there. Then it can present you a dialog asking if it should try again. The dialog will make note it had to use a timer to pull you out of the video player hang and you may not want to try again. But it will offer you the choice to try again because it is your media your way. It will offer to obediently do whatever you want even if it could potentially be the wrong thing to do. This is what happens with your media your way sometimes. The timer will help bring it back. This will eventually get there exactly as I describe. It just takes a little time.

 

Can you show us the media information for that MKV that locks up the Roku? The web app media information. Thanks.

Edited May 9, 2019 by speechles