Feature Request: Better seeking in in-progress recordings on Roku

[ProperlyFormattedDataFile 3]

Currently when I'm playing back a live recording on the Roku, I seem to only be able to seek as far as Emby has transcoded in the background.  This can be frustrating if I want to seek through the first half-hour or hour of a recording.  Would it be possible to change the way Emby handles seeking in ongoing recordings such that it's possible to seek to the middle of the recording and then begin transcoding from there?

Thanks!

[Ljpiru 0]

Roku express +

[ebr 15576]

Hi.  We don't actually handle seeking on the Roku platform as the built in player is in control of that.

 

However, you should be able to seek up unitl the live point so please provide details as to exactly what you're doing and the problem that is occurring.

 

Thanks.

 

How to Report a Problem

[ProperlyFormattedDataFile 3]

Thanks, I'll get you logs tonight.

 

To give a bit more details, I'm attempting to watch a correctly recording program on Roku stick (same behavior on a stick+). When I attempt to seek using the arrows on the remote, the Roku is only able to seek to the end of the transcoding buffer (e.g. if I'm 20 minutes behind live but the server has only transcoded 2 minutes, I can only seek within that 2 minutes).

[ProperlyFormattedDataFile 3]

Hi.  We don't actually handle seeking on the Roku platform as the built in player is in control of that.

 

However, you should be able to seek up unitl the live point so please provide details as to exactly what you're doing and the problem that is occurring.

 

Thanks.

 

How to Report a Problem

 

This isn't a particularly complicated problem to reproduce, so let me know if there's something missing from my descriptions.  I'll try to be as specific as I can be.

 

Server: 4.2.1.0/Linux

Client: Roku Beta 3.1.186 / Roku Stick

 

12:20am EDT: Begin recording Colbert

12:32am: Go to my Recordings library and choose the episode I'm recording, which starts playing immediately

within a couple seconds, hit the right arrow, I can only seek within 8s of buffer.  It's the standard purple roku seek dialog with no thumbnails.

about 15 seconds later, hit the right arrow, I can only seek about a minute.  Same dialog.

about 30 seconds later, hit the left arrow, I can only seek about 2 minutes.  Same dialog.

~12:34am: Upload log from Emby Beta

 

There are a few other playback attempts in the logs before 12:32, but I forgot to upload the log from the emby roku client until that last one.  I also tried an untranscoded, but fully recorded episode from my library and I was able to seek through the whole file in that case.

ffmpeg-transcode-dac28dfe-7bd8-4aaf-aaf5-ff6ae6290fab_1.txt

embyserver.txt

[ebr 15576]

Thanks.  I'm not sure if there is going to be anything we can do about this but we'll look into it.

[speechles 2001]

The setting "DirectStream In-Progress Recordings" is set to YES or NO?

 

If set to NO it should allow full seeking up to the LIVE moment. If it isn't doing this something changed because this has always worked before and we made no changes to this section recently other than to allow better fallback.

 

If set to YES it will only allow you to seek up to the point that has been streamed. You can only seek within that buffer.

Edited October 9, 2019 by speechles

[ProperlyFormattedDataFile 3]

The setting "DirectStream In-Progress Recordings" is set to YES or NO?

 

If set to NO it should allow full seeking up to the LIVE moment. If it isn't doing this something changed because this has always worked before and we made no changes to this section recently other than to allow better fallback.

 

If set to YES it will only allow you to seek up to the point that has been streamed. You can only seek within that buffer.

 

Thanks, it was set to NO, but setting it to YES had no impact (including after exiting and returning to the emby app).  I was still only able to seek within the transcoded buffer.  Do I need to change the option anywhere other than the Roku client?  Logs are attached.  I uploaded the roku client log around 8:30pm EDT.  I made several attempts to seek in the episode between ~8:27 and ~8:30pm.

ffmpeg-transcode-f318fd29-8a23-45f7-88d0-1c6949982098_1.txt

embyserver.txt

Edited October 10, 2019 by ProperlyFormattedDataFile

[speechles 2001]

Thanks, it was set to NO, but setting it to YES had no impact.  I was still only able to seek within the transcoded buffer.  Do I need to change the option anywhere other than the Roku client?  Logs are attached.  I uploaded the roku client log around 8:30pm EDT.

 

Are you using hardware or software transcoding? You also might need to wait for our very next Beta release for Roku. We just put in fixes to correct another issue but it might fix this one at the same time. It is quite possible. After our next Beta release if this does not fix it I will personally set this as highest priority and work on just this tomorrow. I will see if Eric can put out a *hotfix* immediately tomorrow that will include the fix. If this hotfix also fixes your issue we did it. If not I will get with you personally to resolve this issue. We want you happy and I want to reproduce and solve directly. Thanks. Stay tuned for PM from me tomorrow. I will be in contact most defintely after Eric releases the hotfix Beta. Thanks again.

[Happy2Play 9352]

Was just going to ask if disabling HWA makes a difference?

Stream mapping:
  Stream #0:0 (mpeg2_cuvid) -> yadif (graph 0)
  yadif (graph 0) -> Stream #0:0 (h264_nvenc)
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (native))

[speechles 2001]

Here is the ticket:

Fix #615: *HOTFIX* -- EMERGENCY ASAP -- [VideoPlayer] fix fallback to stop hang 

 

This may fix this problem. Once Eric adopts this into the app we can see if this solves this problem as well. It might it might not. If it does not I will personally work with you to resolve this issue. Stay tuned.

Edited October 10, 2019 by speechles

[ProperlyFormattedDataFile 3]

Thanks for the quick responses. I just tried disabling hardware encoding, but didn't observe any differences. I'll give the app fix a try once it goes out.

[Luke 39640]

This isn't a particularly complicated problem to reproduce, so let me know if there's something missing from my descriptions.  I'll try to be as specific as I can be.

 

Server: 4.2.1.0/Linux

Client: Roku Beta 3.1.186 / Roku Stick

 

12:20am EDT: Begin recording Colbert

12:32am: Go to my Recordings library and choose the episode I'm recording, which starts playing immediately

within a couple seconds, hit the right arrow, I can only seek within 8s of buffer.  It's the standard purple roku seek dialog with no thumbnails.

about 15 seconds later, hit the right arrow, I can only seek about a minute.  Same dialog.

about 30 seconds later, hit the left arrow, I can only seek about 2 minutes.  Same dialog.

~12:34am: Upload log from Emby Beta

 

There are a few other playback attempts in the logs before 12:32, but I forgot to upload the log from the emby roku client until that last one.  I also tried an untranscoded, but fully recorded episode from my library and I was able to seek through the whole file in that case.

 

We are looking into improving it. Thanks for reporting.

[ProperlyFormattedDataFile 3]

We are looking into improving it. Thanks for reporting.

 

Thanks!  Looking forward to it.

[speedingcheetah 39]

Really would like to see the full time code, HH;MM:SS when playing back recordings and local media.

This format is thre for live tv. and i also see it native in other roku apps.

Also, very much would like seeking to NOT have to press enter to play...just want it to work same as on computer, skip by so many secs and it auto plays. faster eaiser,

[ebr 15576]

Really would like to see the full time code, HH;MM:SS when playing back recordings and local media.

 

Hi.  Not sure what you mean here.  Where are you not seeing this?

 

 

Also, very much would like seeking to NOT have to press enter to play...just want it to work same as on computer, skip by so many secs and it auto plays. faster eaiser,

 

That's just the way the Roku player is designed.  Unfortunately, we don't control that.

[speedingcheetah 39]

Hi.  Not sure what you mean here.  Where are you not seeing this?

 

 

 

That's just the way the Roku player is designed.  Unfortunately, we don't control that.

 

When u seek things, the bar on the bottom.  see pics

 

Local file playback, it only shows  #h #m.

Live TV playback:  #m #s

 

Local file playback is thus missing the seconds field on both side of the bar, current position/ remaining.

 

I swear i had an app 2  that do not require to press OK or play when seeking and resuming....

[ebr 15576]

Okay, both of those are the standard Roku player UI.  I'm not sure how much this could be customized but we tend to like to keep it standard so it is familiar to Roku users.

[speechles 2001]

That is because LiveTV technically has no end. So to the Roku Player UI it has no real idea what the actual runtime is. It cannot know the true full length so can only display the buffer that has so far been captured. Whereas the actual file playing knows the full runtime. It can properly display the full runtime as that is known ahead of time. You get this when you press LEFT or RIGHT on the remote.

 

When you press UP or DOWN and use the Emby UI it will properly show the same transport bar for both files and liveTV as that bar can use the guide to determine runtime of liveTV. The Roku Player UI does not have that luxury. You cannot adjust the transport bar in the Emby UI as that is used for Emby functionality. The Roku Player UI is used to seek. It is supposed to show you thumbnail BIF during this but liveTV also lacks that luxury.

Edited October 16, 2019 by speechles

[speedingcheetah 39]

That is because LiveTV technically has no end. So to the Roku Player UI it has no real idea what the actual runtime is. It cannot know the true full length so can only display the buffer that has so far been captured. Whereas the actual file playing knows the full runtime. It can properly display the full runtime as that is known ahead of time. You get this when you press LEFT or RIGHT on the remote.

 

When you press UP or DOWN and use the Emby UI it will properly show the same transport bar for both files and liveTV as that bar can use the guide to determine runtime of liveTV. The Roku Player UI does not have that luxury. You cannot adjust the transport bar in the Emby UI as that is used for Emby functionality. The Roku Player UI is used to seek. It is supposed to show you thumbnail BIF during this but liveTV also lacks that luxury.

 

This is backwards to me what u say. perhaps u not understand.

 

Local file playback....u know the full duration....but the ui is NOT showing the seconds value. (when use Emby)

Live tv playback, unknown full duration.....ui IS showing the seconds value.

 

No reason that the secs value can not be displayed as well as the hour and min....regardless of the video source.

 

Edit: I am now useing the beta app....so the UI is a tad tad differnt than the images i posted previous.

Edited October 16, 2019 by speedingcheetah

[speechles 2001]

This is backwards to me what u say. perhaps u not understand.

 

Local file playback....u know the full duration....but the ui is NOT showing the seconds value. (when use Emby)

Live tv playback, unknown full duration.....ui IS showing the seconds value.

 

No reason that the secs value can not be displayed as well as the hour and min....regardless of the video source.

 

That is because the bar has two fields.. major and minor. In your case when the file is small there is no hour. It defaults to minute for major and seconds is minor. The hour only becomes major when the runtime is beyond 60 minutes. Same with seconds missing with larger runtime items. It only shows hours and minutes but no seconds. This is a Roku Player UI deficiency. We would have to develop our own component to get this any different. We eventually will need to roll-our-own component for that eventually but we have a lot of other issues bigger than this on our tracker. I can add this to our tracker though to give it eyeballs.

 

Reference: Issue #617: [Roku Player UI] Hours:Minutes:Seconds ( three fields versus two fields ) 

Edited October 16, 2019 by speechles

[speedingcheetah 39]

Ah well that now makes much more sense as to why this happens, thank you.

[ProperlyFormattedDataFile 3]

That is because LiveTV technically has no end. So to the Roku Player UI it has no real idea what the actual runtime is. It cannot know the true full length so can only display the buffer that has so far been captured. Whereas the actual file playing knows the full runtime. It can properly display the full runtime as that is known ahead of time. You get this when you press LEFT or RIGHT on the remote.

 

When you press UP or DOWN and use the Emby UI it will properly show the same transport bar for both files and liveTV as that bar can use the guide to determine runtime of liveTV. The Roku Player UI does not have that luxury. You cannot adjust the transport bar in the Emby UI as that is used for Emby functionality. The Roku Player UI is used to seek. It is supposed to show you thumbnail BIF during this but liveTV also lacks that luxury.

 

The problem is that there are two buffers.  The important buffer, and the one I expect to be able to seek in, is the video that I've recorded already that runs from the start of the recording to now.  The buffer that I'm able to seek in the Roku is different, it's the buffer that my Emby server has transcoded from mpeg2 to H.264.  This buffer starts at 0, and resets any time I leave the playback.  Additionally, seeking in the buffer doesn't work particularly well, as the Roku will sometimes reset my progress all the way to the end of the buffer when I've only watched a few minutes of the recording and will only pause for a couple minutes before it runs out of internal storage and unpauses itself.

 

When I'm watching a fully recorded program, I have none of these limitations.  The Roku can seek through the full extent of the recorded mpeg2 file, even though I may only have a minute or so transcoded.  Additionally, pausing doesn't magically unpause itself after a couple minutes and I've yet to see progress jump around in unpredictable ways.  What I'm hoping to see is the same sort of ability to seek in currently recording programs as I see in programs that have already finished.

 

Thanks