borngborn 0 Posted September 29, 2018 Share Posted September 29, 2018 Im using the beta roku app beceause the original wont start direct streaming when audio is not supported it automatically starts converting both audio and video instead of just audio, but with a unsupported audio file on the beta app it will just re-encode audio and repackage while still sending the original video file with HDR threw to my tv but recently with the beta app it started causing a blurry screen like the kind it gives u when u turn to a cable channel thats not in service the white black fuzz but instead its RGB fuzz lol please help i attached my log. Link to comment Share on other sites More sharing options...
Luke 37132 Posted September 29, 2018 Share Posted September 29, 2018 Hi there, can we look at an example? please attach the information requested in how to report a media playback issue. thanks ! Link to comment Share on other sites More sharing options...
speechles 1920 Posted September 30, 2018 Share Posted September 30, 2018 (edited) Can you please try again with Emby Roku Beta. Presently this is Version 3.0 build 110. This version has a rebuilt fallback mechanism which replaced the one that was likely causing you grief. If this does resolve the issue can you please mark this thread as answered. Otherwise, please help us by seeing luke's post above. We need to know why this happens, how it happens, and what we would need to do to fix it. This requires knowing how we can possibly reproduce it on our end. Part of that requires knowing some things on your end. If this is still an issue once we know that information we will know what answers to give you and what else to say. Thanks. Edited September 30, 2018 by speechles Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 1, 2018 Author Share Posted October 1, 2018 i thought i added my emby log guess it never uploaded yest im going to try again tonight Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 1, 2018 Author Share Posted October 1, 2018 No still doing the same thing i think this is the correct log emby log.txt Link to comment Share on other sites More sharing options...
Happy2Play 8318 Posted October 1, 2018 Share Posted October 1, 2018 My guess would be pgssub subtiltle burn in Stream mapping: Stream #0:0 (hevc) -> overlay:main (graph 0) Stream #0:7 (pgssub) -> scale (graph 0) scale (graph 0) -> Stream #0:0 (libx264) Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native)) The Roku platform supports the following closed caption formats: SMPTE-TT EIA-608/708 WebVTT SRT 1 Link to comment Share on other sites More sharing options...
speechles 1920 Posted October 1, 2018 Share Posted October 1, 2018 (edited) My guess would be pgssub subtiltle burn in Stream mapping: Stream #0:0 (hevc) -> overlay:main (graph 0) Stream #0:7 (pgssub) -> scale (graph 0) scale (graph 0) -> Stream #0:0 (libx264) Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native)) The Roku platform supports the following closed caption formats: SMPTE-TT EIA-608/708 WebVTT SRT You are correct. TranscodeReasons=SubtitleCodecNotSupported This can be fixed with a quick MKVToolNix GUI Remux. Uncheck the PGS subtitles, leave everything else checked. Start Remux. Now let emby get SRT subtitles for that file. Edited October 1, 2018 by speechles Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 1, 2018 Author Share Posted October 1, 2018 the RGB fuzz happens on other video files also even when not using subtitles Link to comment Share on other sites More sharing options...
Happy2Play 8318 Posted October 2, 2018 Share Posted October 2, 2018 the RGB fuzz happens on other video files also even when not using subtitles How about another ffmpeg log without subtitles. Probably the transcode process hevc to h264, don't you loss HDR? Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 2, 2018 Author Share Posted October 2, 2018 heres anthor ffmpeg no subs and no i dont wana lose HDR im not transcoding video just audio. the only reason im using beta app is cuz i cannot dirrect stream with the normal emby app i just doesnt happen which sucks New Text Document.txt Link to comment Share on other sites More sharing options...
Happy2Play 8318 Posted October 2, 2018 Share Posted October 2, 2018 @@speechles I am guessing but would this be a ts container issue? Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 2, 2018 Author Share Posted October 2, 2018 (edited) no its a mkv not m2ts and it was working perfectly a couple of days ago the original emby app works fine and i tried emby beta and regular servers is their a way to force direct stream on the original emby app not the beta Edited October 2, 2018 by borngborn Link to comment Share on other sites More sharing options...
Happy2Play 8318 Posted October 2, 2018 Share Posted October 2, 2018 (edited) no its a mkv not m2ts and it was working perfectly a couple of days ago the original emby app works fine and i tried emby beta and regular servers is their a way to force direct stream on the original emby app not the beta No look at the log, both video (copy) and audio(converted) are repacked into TS.. There have been lot of logic update in beta so there many issues still. C:\Users\user\AppData\Roaming\Emby-Server\system\ffmpeg.exe -noaccurate_seek -f matroska -i file:"F:\Plex Server 2\4k Movies\X-Men.Days.of.Future.Past.2014.2160p.UHD.BluRay.X265-IAMABLE\X-Men.Days.of.Future.Past.2014.2160p.UHD.BluRay.X265-IAMABLE (NO SUB).mkv" -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 copy -copyts -vsync -1 -codec:a:0 ac3 -ac 6 -ab 384000 -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3 -individual_header_trailer 0 -break_non_keyframes 1 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 0 -segment_list "E:\Plex Server\Trans\transcoding-temp\acf40427e3eda99e8122bc722fea63e2.m3u8" -y "E:\Plex Server\Trans\transcoding-temp\acf40427e3eda99e8122bc722fea63e2%d.ts" Edited October 2, 2018 by Happy2Play Link to comment Share on other sites More sharing options...
speechles 1920 Posted October 2, 2018 Share Posted October 2, 2018 (edited) no its a mkv not m2ts and it was working perfectly a couple of days ago the original emby app works fine and i tried emby beta and regular servers is their a way to force direct stream on the original emby app not the beta Thats the beauty of the new beta app. It has multiple fallback levels now. If you haven't used it recently there were changes even today. This will be an ever evolving process which with your help makes it easier on others tomorrow. So bear with us, and please try your tests with the beta. Any information your tell us about the stable, isn't useful for tomorrow. The beta is the product which becomes the stable. If you need to get your issues fixed at the fastest speed possible we need you to be with us where we can provide the fastest assistance. Roku makes their roku store require approval for updates. They don't if it is a private application, such as the beta, and you can push updates in real-time. Without waiting for Roku to finally allow the store to update devices with your new update. So it is most helpful to stay on the beta to provide help. Using the stable is great, the majority do. But their issues on that branch may no longer even be relevant. That is why it is the most help, for us, if we are on the same page. The same builds of the app. Reproduce the issue identically and then get it solved. Please continue to trust your best intentions are always in mind. Playback is #1 priority. Guaranteed by me that playback issues halt development and feature improvements until solved. The reality is it will get better. Bear with us and try the new beta version. If it is again something not working as desired we can continue the conversation with more accurate information. Thanks. BTW, the fallback detection in the app is tested in the battlefield. If this were a bigger issue we would be on fire with complaints. I am working to keep those fires from ever happening.. well.. again ever. The app will play your files or we aren't doing our jobs. Thanks for listening. I want you to be happy. No look at the log, both video and audio are repacked into TS, audio trascode during the repack. There have been lot of logic update in beta so there many issues still. C:\Users\user\AppData\Roaming\Emby-Server\system\ffmpeg.exe -noaccurate_seek -f matroska -i file:"F:\Plex Server 2\4k Movies\X-Men.Days.of.Future.Past.2014.2160p.UHD.BluRay.X265-IAMABLE\X-Men.Days.of.Future.Past.2014.2160p.UHD.BluRay.X265-IAMABLE (NO SUB).mkv" -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 copy -copyts -vsync -1 -codec:a:0 ac3 -ac 6 -ab 384000 -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3 -individual_header_trailer 0 -break_non_keyframes 1 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 0 -segment_list "E:\Plex Server\Trans\transcoding-temp\acf40427e3eda99e8122bc722fea63e2.m3u8" -y "E:\Plex Server\Trans\transcoding-temp\acf40427e3eda99e8122bc722fea63e2%d.ts" It might be simply someone remuxed the MPEG2 from a TS into an mkv (the roku might see this in the header and act like its a ts) but these should direct play, or direct stream, or at the very least remux. If he still has an issue the next question after he tries the next beta is, what type of roku device is this? Edited October 2, 2018 by speechles Link to comment Share on other sites More sharing options...
Happy2Play 8318 Posted October 2, 2018 Share Posted October 2, 2018 It might be simply someone remuxed the MPEG2 from a TS into an mkv (the roku might see this in the header and act like its a ts) but these should direct play, or direct stream, or at the very least remux. If he still has an issue the next question after he tries the next beta is, what type of roku device is this? The full ffmpeg log is in post 10. Link to comment Share on other sites More sharing options...
speechles 1920 Posted October 2, 2018 Share Posted October 2, 2018 (edited) The full ffmpeg log is in post 10. Thanks. Completely overlooked.. Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native)) Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600 [SAR 1:1 DAR 12:5], q=2-31, 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc (default) Stream #0:1: Audio: ac3, 48000 Hz, 5.1, fltp (24 bit), 384 kb/s (default) We aren't removing your HDR. In fact, it is right there in the p10. We are copying the streams to your Roku. The DTS is being converted to Dolby AC3 correctly. I do not see a good reason it won't play. We are honestly not transcoding to H264 now when the HEVC HDR can be copied untouched. This is what we are doing. So we are doing everything possible to work in the most efficient way possible. The Roku firmware was recently updated on some models. This is why I ask, which Roku models is this, and what firmware is it running? Edited October 2, 2018 by speechles Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 5, 2018 Author Share Posted October 5, 2018 its the new TCL 6 series Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 5, 2018 Author Share Posted October 5, 2018 now niether emby regular or beta are allowing me to just direct play compatible formats its forcing a transcode on movies that wuld direct play before Link to comment Share on other sites More sharing options...
Luke 37132 Posted October 5, 2018 Share Posted October 5, 2018 Can we please look at an example? Thanks ! Link to comment Share on other sites More sharing options...
speechles 1920 Posted October 5, 2018 Share Posted October 5, 2018 now niether emby regular or beta are allowing me to just direct play compatible formats its forcing a transcode on movies that wuld direct play before Can you provide an ffmpeg example? There might still be ghosts in the machine, but the detection shouldn't be causing issues to get worse. The only real change that occured is when profiles are sent. Now they get sent before every playback as the fallback detection is allowed to change these. So if there is an error in the stream, the app will now resume with a fallback method, not necessarily the play method it was in. This is by design and might be why this is occuring. If you believe it is happening incorrectly providing the ffmpeg log is the best way to give an example. Thanks. Link to comment Share on other sites More sharing options...
Luke 37132 Posted October 5, 2018 Share Posted October 5, 2018 @@borngborn yes let's please look at an ffmpeg log from an example. thanks ! Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 6, 2018 Author Share Posted October 6, 2018 Here is a log with a MKV that used to be able to direct play now does not for some reason my TV handles Dolby 5.1 Natively so no transcode should be necessary Link to comment Share on other sites More sharing options...
Happy2Play 8318 Posted October 6, 2018 Share Posted October 6, 2018 Here is a log with a MKV that used to be able to direct play now does not for some reason my TV handles Dolby 5.1 Natively so no transcode should be necessary Did you PM the log or forget to attach it? Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 6, 2018 Author Share Posted October 6, 2018 here it is i thought i attached it before to but guess it didnt Link to comment Share on other sites More sharing options...
borngborn 0 Posted October 6, 2018 Author Share Posted October 6, 2018 my bad now here it is this is a movie that wuld direct play recently now no longer does LOG.txt Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now