csadoian 34 Posted January 19, 2019 Share Posted January 19, 2019 Not sure if this problem is unique to server version 4, but I have noticed that I cannot resume a Podcast when using my Roku 3. I can play a Podcast if I start from the beginning, but if I either try to resume at a later time or fast forward a few minutes into the show Roku will show me a loading screen and a progress bar of about 1/4. Then it just appears to hang. When playing from the beginning the server dashboard shows a green line and a red line underneath it. When trying to resume, it shows only the green line. I do not have issues resuming using other clients, such as with Chrome on Windows, Android or Emby Theater on Windows. It only seems to affect the Roku 3. I also do not have any issues resuming a recording made locally by Emby, or other local media files (such as movies). The picture shows the dashboard just after I hit resume. If I wait long enough I get a red line under the green line, the Throttle goes "Active" and the Roku screen changes to just the Podcast title and "Retrieving", but still no video. I have waited about 5 minutes at this screen, but it never starts playing again. embyserver-63683485391.txt ffmpeg-transcode-84b04820-e1d3-40c4-b0b4-9b56fe4aafdf_1.txt hardware_detection-63683485309.txt Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 19, 2019 Share Posted January 19, 2019 What if you disable hardware acceleration and try? Does this exhibit the same problem? Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 What if you disable hardware acceleration and try? Does this exhibit the same problem? Yes, same problem. Hardware acceleration appears to have no affect. Since it only seems to be happening on Podcasts it may have something to do with the Podcast Plugin? Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 19, 2019 Share Posted January 19, 2019 (edited) Yes, same problem. Hardware acceleration appears to have no affect. Since it only seems to be happening on Podcasts it may have something to do with the Podcast Plugin? When we resume we request the stream "into the future". If this is a live-stream resume is not an option and we need to be able to disable the resume button in that instance. But if this is a file stored on their end, and the IPTV endpoint just streams this it should allow resume. If you set the maximum video bitrate in the settings below the bitrate of the IPTV stream it should force a transcode. It will be lesser quality but when it does this does it allow resume? I am guessing it will have the same problem if this should be a "livestream" but might work if this is an issue with allowing direct video copy. Doing a transcode of the video stream might help. Edited January 19, 2019 by speechles Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 After I wrote the comment about the problem possibly being the Podcast plugin, I realized that it is only happening on the Roku and not with other clients, so I would think that would rule out the plugin. I changed the video quality to force a transcode down to 480 and I still have the problem on the Roku. When I started the playback the server dashboard reported it was transcoding. I then tried to resume 32 minutes into the 1 hour podcast, and it did the same thing. After resuming, the server dashboard reported "Direct Playing", and the Playback position was at 53.9%, and the Transcode position began a slow "walk" from 1% on up. At around 44% the playback position started incrementing slowly, but the Roku was still stalled. Eventually the numbers at the bottom completely disappeared, leaving only "Direct Playing". Still no action on the Roku. At that point the server dashboard was still reporting direct playing, but the only numbers displayed were above the green bar (example: 39.22/1:05:20). The first number was slowly incrementing, but the Roku was just stuck. Within a few more minutes the server dashboard showed the playback was stopped, but the Roku was still on the "Retrieving" screen. Eventually the Roku went into "Screen Saver" mode. I hit a key on the remote and it went back to the "Retrieving" screen, and then I hit the back arrow and Emby went back to the main screen. Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 (edited) By the way, the podcast feed I'm using is: http://feeds.twit.tv/hn_video_hd.xml Edited January 19, 2019 by csadoian Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 19, 2019 Share Posted January 19, 2019 (edited) http://www.podtrac.com/pts/redirect.mp4/cdn.twit.tv/video/hn/hn0385/hn0385_h264m_1280x720_1872.mp4 Their urls are using a redirect inside them. Then it redirects you to the media you want. It is this part the app doesn't know to cut that redirect out. It is the redirect killing the resume. @@Luke How do we handle this? Do I just use regexp to get the correct url and just use that and as people come forward with issues like this add more redirect removers with regexps to the app? This would fix the problem, but I want your opinion. This is a sort of delicate legal area. EDIT: Let me explain the legal problem. They are using the redirect to insert their promotions/advertising/etc before sending you to the actual content you requested. We strip them of this with a redirect remover. Hence the quandry. I want clean hands. Edited January 19, 2019 by speechles Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 http://www.podtrac.com/pts/redirect.mp4/cdn.twit.tv/video/hn/hn0385/hn0385_h264m_1280x720_1872.mp4 Their urls are using a redirect inside them. Then it redirects you to the media you want. It is this part the app doesn't know to cut that redirect out. It is the redirect killing the resume. But why only in Roku? Doesn't seem to affect my other clients ... Link to comment Share on other sites More sharing options...
Luke 37024 Posted January 19, 2019 Share Posted January 19, 2019 Can you resume in the web app? Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 19, 2019 Share Posted January 19, 2019 (edited) @@csadoian The Roku is an entirely different creature. We simply feed its video player component a url and tell it go. Then we control the transport controls, and some other variables that affect what/how it plays. We cannot control much else when playing directly. If it was forced to transcode it should allow a resume even with the redirect. Also, the resolution shown with the video bitrates is actually.. erm.. meaningless so to speak. It is just a way to sort the bitrates as the Roku can only show so many of them at one time. So please when you want to go under the bitrate of the item use the bitrate not so much the resolution shown to force this. If you force the stream to 400p does it resume? Not saying this is acceptable and now just always use 400p either. Just to see if this does play. If it does we can figure out how to better auto-detect redirects and force a transcode in this case. Edited January 19, 2019 by speechles Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 Can you resume in the web app? Using Chrome, yes. Android app seems to have the same issue with the internal player. I normally run my Android app using an external player (MX Player) and using it I do not have a problem. Link to comment Share on other sites More sharing options...
Luke 37024 Posted January 19, 2019 Share Posted January 19, 2019 For now it just might not work then, as we are dependent on the client video player being able to handle that, and if it can't then there will be a problem. Maybe we can have some option to force them to always transcode, then I would think they'll work. Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 For now it just might not work then, as we are dependent on the client video player being able to handle that, and if it can't then there will be a problem. Maybe we can have some option to force them to always transcode, then I would think they'll work. @@speechles suggested I force a transcode, and that didn't help. See #5. Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 19, 2019 Share Posted January 19, 2019 @@speechles suggested I force a transcode, and that didn't help. See #5. Can you provide the ffmpeg log from that attempt. I am sorry I can't just snip the redirect. In this climate with so many things it isn't ethical to strip that redirect. I hope you understand. This is beyond my control. But.. as far as something that won't get me in trouble.. I was hoping the transcode would work. If it doesn't all I can suggest is that we can see the ffmpeg log from those sessions that fail. In this way we can learn how to perhaps solve this without resorting to black hattery. Thanks. Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 Here are the two transcode logs. ROKU-1 is when I started the podcast from the beginning. ROKU-2 is when I tried to resume from 30 minutes in. Using Chrome I also took the same steps but no transcode logs are generated. I assume this is because Chrome can play the video format natively, while the ROKU cannot. Therefore the resume problem occurs when using a device that requires transcoding. If no transcoding is necessary there doesn't seem to be a problem with resuming (this is just an assumption on my part, based on my observations). By the way, this is not a major problem for me. I can work around it. However, since I experienced the issue I thought it would be best to report it. Thanks. ffmpeg-transcode-ROKU-1.txt ffmpeg-transcode-ROKU-2.txt Link to comment Share on other sites More sharing options...
Luke 37024 Posted January 19, 2019 Share Posted January 19, 2019 if you force a transcode in the web app using the quality settings, does it play? the ffmpeg logs are at least encouraging, in that ffmpeg doesn't appear to have any problem with the redirect. Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 19, 2019 Share Posted January 19, 2019 (edited) h t t p : / / 192.168.60.93:8096/emby/videos/38153/hls1/main/0.ts?DeviceId=4d8357b1-1f0a-5f21-b433-d3451a117c4f&MediaSourceId=74a695597dfd97b7cd2fa241a218c3ba&VideoCodec=h264,mpeg2video&AudioCodec=aac,mp2,mp3,flac,opus,vorbis,lpcm&VideoBitrate=79808000&AudioBitrate=192000&MaxFramerate=61&MaxWidth=1920&MaxHeight=1080&PlaySessionId=e9b10b972028433ebae498aeeb352371&api_key=a0517a7cbf444c75b6df9ee037a57cc6&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 Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native)) Stream #0:1 -> #0:1 (aac (native) -> aac (native)) Why is it converting h264 into mpeg2video? It should be using h264 according to the above as the default aka needs transcoding codec. The others are just to stream copy. Something is weird here. Edited January 19, 2019 by speechles Link to comment Share on other sites More sharing options...
csadoian 34 Posted January 19, 2019 Author Share Posted January 19, 2019 if you force a transcode in the web app using the quality settings, does it play? the ffmpeg logs are at least encouraging, in that ffmpeg doesn't appear to have any problem with the redirect. @@Luke I can't seem to be able to force a transcode in Chrome. I put the quality all the way down to 360p but no transcode, just direct play. When I click on the gear icon in the playback screen the Quality is reported as 360p, but it's definitely not 360p. Stats for nerds says DirectPlay, video resolution 1280 x 720. Link to comment Share on other sites More sharing options...
Luke 37024 Posted January 20, 2019 Share Posted January 20, 2019 Ok thanks for the info. 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