Version 82.0 Roku app - playback controls don't work for recordings

[DSperber]

Many mentions in many threads of broken version 81.0 of Roku app (playing on both of my Ultra 4800's, one with LG OLED C7 and the other with LG OLED C9). Could not play recording, which attempt caused app to crash and return to Roku home screen.

New release 82.0 out today fixes the primary problem, which is the inability to play a recording.

However...

(1) As has been stated in another thread, the purple navigation arrow keys (right-arrow, left-arrow) that surround the OK button in what is also known as the "D-pad" are non-functional. For all other streaming apps the purple right-arrow is functionally equivalent to the black FF button (in the center of the remote, to the right of the PLAY/PAUSE button) and the purple left-arrow is functionally equivalent to the black REW button (in the center of the remote, to the left of the PLAY/PAUSE button). When watching a recording with the Roku HDHR app version 82.0 pressing the purple navigation arrow keys does nothing.

(2) Pushing the black PLAY/PAUSE button while playing a recording causes the onscreen video to pause (i.e. "freeze") but the audio continues un-paused. When the PLAY/PAUSE button is pressed a second time to resume playback, the video is now presented in a super-fast mode so that it eventually catches up to where the audio has moved on to while it was continuing un-paused. Once the super-fast video catches up to the audio normal video speed returns and all is normal again.

(3) With version 82.0 the FF and REW functions appear broken. The first time the FF button is pressed it appears to initiate the expected FF operation. The screen goes black (no audio or video), a "fuel gauge" bar appears and a white "progress indicator" begins to grow towards the right, implying the fast forward operation that was requested. However now pushing PLAY/PAUSE (presumably to resume playback of audio/video at whatever point in the recording the FF operation has arrived at) does not bring back audio/video to the screen. In fact it appears the app has crashed, as no buttons on the remote seem to work. The screen is black, pushing any of the FF, REW, PLAY/PAUSE buttons causes a sound (perhaps an error message?) but the screen is black so I don't know what's going on. Pushing HOME on the remote returns to Roku home screen, and re-entering HDHR app starts the app up again (with SD logo).

(4) After restarting the HDHR app, reattempting the playback of a recording no longer starts playback. Instead, the fuel gauge reappears suggesting it is still trying to FF, as if somehow the app believes it wants to pick up where it last was. There's no way to restart playback at the very beginning of the recording, nor even to ever again get audio and video back on the screen. Totally broken.

(5) I've tried removing the app from my Roku home screen, and re-installing. Doesn't seem to have made a difference, as trying to play the recording persists in presenting the fuel gauge with white portion where it last left off when I pushed the PLAY/PAUSE button on the remote to stop the FF operation I'd initiated.

(6) Even when that FF operation started, there is no "time code" or "visual thumbnail" presentation so that there is any clue as to where the FF (or REW) operation might be. This is not live TV, it is a recording. So surely there should be at least a 0:00.00 displayed on the left of the fuel gauge, and some HH:MM.SS on the right of the fuel gauge to show the length of the recording. And over the fuel gauge there really should be some kind of a time clock or frame thumbnail displayed to reinforce where the FF/REW operation is at that instant. Without any type of visual feedback the FF/REW operation is really inferior... even if it worked, which at the moment it does not.

(7) I am going to try and reboot the Roku, hoping that might fix the HDHR app that appears to be stuck at the moment in an incomplete FF operation with no way to reset things. I supposed I could also delete that recording and pray this un-sticks things so that I might be able to make a new recording and experiment again with playback. But for now I am simply reporting that version 82.0 is unable to FF/REW through a recording that it is now once again capable of beginning playback for. But beyond that, PAUSE/PLAY is broken, FF/REW is broken, and once the breakage occurs it is no longer possible to play a recording. (actually I only have on recording that I've been using for testing, so maybe if I had a second recording that would provide a way to un-stick things).


===>> go back to the lab and debug this thing!

[DSperber]

So I've now tried to create a second recording, on the off-chance its presence will un-block the problem recording I've been trying unsuccessfully to play after having experimented with FF.

I cannot seem to initiate a new recording of live TV (not through setting a scheduled recording, but simply pushing OK to get the slice guide, then purple-right-arrowot-OK on the selected channel to pop it out, then OK to produce the record-on-demand popup, then navigate to "record this airing" and OK, then OK on "set recording"). Presumably recording of this live channel is now initiated (at least I think it should be). Then BACK to clear the slice guide, etc..

However then pushing BACK button to produce HDHR main screen (Live | Recorded | Discover) shows nothing under recordings (other than the previously existing recording). So there is no new active in-progress recording going on, apparently.

Note that I still cannot resume playback of that original previous recording, which I tried the FF with. It's just stuck. Fuel gauge appears for about 5 seconds, with small white piece at the front (much less than what I had FF'd to), then disappears and screen goes black with no sound. I push BACK and return to recording information screen, so the app doesn't seem to have crashed. It just can't play the recording.

[DSperber]

Ok. I am now going to provide VIDEO PROOF of everything I've stated above: PLAY/PAUSE and FF/REW player control functions are broken in Roku HDHR app v82 running on Ultra 4800 12.5.0 to LG OLED C9!!! SEE BELOW in next post!!!

But first, NEW DISCOVERY: I had theorized that the problem with FF is that the "repositioned playback location, which is supposed to be 30-second skip forward" must somehow be stored in the INI/CFG (or whatever) file is associated with the recording that allows "resume" from any HDHR app client on the network. My hypothesis was that maybe it was only v82 of the Roku app that was broken and could not actually resume playback after the 30-second skip forward resulting from pushing FF, nor could a relaunch of the app correctly position itself at the prescribed location if playback of the recording was re-attempted after the re-launch of the app. So the Roku v82 app appeared "stuck" on that recording, being unable to play it either from the very beginning or from its 30-second skip forward location once it had gotten "stuck" by pushing FF.

But my thought was that perhaps if I used a different HDHR client (e.g. ATV4K which I also have on my LAN) that COULD RESUME PROPERLY from the 30-second skip forward location, that this might "un-stick" playback of the recording. And then, maybe, if I got back into the Roku v82 app, well maybe I could now resume playback of the recording from wherever that other [ATV4K] HDHR app had left off. This was my thought.

So that's what I just tried. Started playback of the recording which had gotten "stuck" by the Roku v82 app by pushing FF. The Roku HDHR app could no longer play/resume playback of that recording... it was "stuck". But when I then used the ATV4K HDHR app sure enough it WAS able to play the very recording which was "stuck" for Roku HDHR. And sure enough, it seemed to resume playback exactly at that 30-second skip-forward location which the FF function used on the Roku should have established. In other words, playback was now seemingly "unstuck". After watching a bit, and using FF successfully in the ATV4K HDHR app in order to skip forward 30-seconds per FF, I then stopped playback in ATV4K. Obviously, the INI/CFG location positioning information was correctly stored by the exiting ATV4K app.

And now I got back into the Roku HDHR app, selected that recording for playback, and sure enough playback started, resuming from the exact location where the ATV4K HDHR app had left off when it exited. So not only was the Roku v82 HDHR app now "unstuck" on this recording (thanks to using the ATV4K HDHR app), but apparently when playback of a recording is launched it has the ability to properly read and use the positioning information in the INI/CFG data. It's problem is simply that when using FF (during playback) to perform the 30-second skip forward and save that location pointer in the INI/CFG, it appears unable to then properly resume normal playback of audio/video from that new location. Black screen.

==> Roku v82 HDHR app FF function (and probably REW function as well, but I haven't tried that) appears to correctly skip forward 30-seconds and set the correct location pointer in INI/CFG for the recording. But it does not resume playback, instead just getting "stuck" with black screen. If the app is then exited, and then relaunched, and then that "stuck" recording selected for playback and OK to presumably resume playback at the correct location, it again results in a black screen. Playback does not resume as expected. But if I clear things up by using the ATV4K HDHR app, which DOES resume at the correct location, and then exit the ATV4K app, when I then relaunch the Roku app and try playing that recording, sure enough it now works perfectly, resuming play at the correct location as left by the ATV4K app when it exited.

[DSperber]

Problem (2) posted above:

(2) Pushing the black PLAY/PAUSE button while playing a recording causes the onscreen video to pause (i.e. "freeze") but the audio continues un-paused.

When the PLAY/PAUSE button is then pressed a second time to resume playback, the video is now presented in a super-fast mode so that it eventually catches up to where the audio has moved on to while it was continuing un-paused. Once the super-fast video catches up to the audio normal video speed returns and all is normal again.

-----------------------------------------------------------------------------------------------------------

Here is a video of exactly the above scenario.

Playback of a recording is started, and normal audio/video begins. I then push PAUSE/PLAY to theoretically pause BOTH audio and video, expecting a "frozen" image on the screen. Well the image does freeze, but the audio continues normally as if PAUSE/PLAY had never been pressed.

I let it run like this, "frozen-video, normal audio", for about 15 seconds.

I then pushed PAUSE/PLAY again, which theoretically should resume normal playback of audio and video. However the audio has been continuing normal speed playback for this entire 15 seconds. So now the video is actually 15 seconds BEHIND THE AUDIO.

Amazingly, the video is now presented in "high-speed fast forward" mode while the audio continues to play at normal speed even further along from that first 15-second unit. So the video had to "catch up" to not only the 15-seconds when it was paused/frozen, but during the next few seconds of audio as well.

Eventually the video in super-fast high-speed mode DOES catch up to the audio, and now video returns to normal speed to match the normal speed audio at that point.

[DSperber]

Problem (3) posted above:

(3) With version 82.0 the FF and REW functions appear broken. The first time the FF button is pressed it appears to initiate the expected FF operation. The screen goes black (no audio or video), a "fuel gauge" bar appears and a white "progress indicator" begins to grow towards the right, implying the fast forward operation that was requested. However now pushing PLAY/PAUSE (presumably to resume playback of audio/video at whatever point in the recording the FF operation has arrived at) does not bring back audio/video to the screen. In fact it appears the app has crashed, as no buttons on the remote seem to work. The screen is black, pushing any of the FF, REW, PLAY/PAUSE buttons causes a sound (perhaps an error message?) but the screen is black so I don't know what's going on. Pushing HOME on the remote returns to Roku home screen, and re-entering HDHR app starts the app up again (with SD logo).

-------------------------------------------------------------------------

Here is a video of exactly the above scenario.

Note that attempting this same FF function using ATV4K HDHR app, there isn't a need to push PLAY/PAUSE to resume playback. In other words, the FF is really just a single "skip forward 30-seconds". It is not a "continuous and indefinite FAST-FORWARD untio PAUSE/PLAY is pushed to resume normal playback at whatever point has been reached".

So the single FF using the Roku v82 HDHR app should do the same thing, namely skip forward 30-seconds and resume audio/video playback at that point. But it does not.

[DSperber]

Problem (4) posted above:

(4) After restarting the HDHR app, reattempting the playback of a "stuck after FF" recording no longer starts playback. Instead, the fuel gauge reappears suggesting it is still trying to FF or reposition and resume playback at the new location, as if somehow the app believes it wants to pick up where it last was. But this simply fails on the Roku v82 HDHR app (even though it works perfectly if I instead use the ATV4K HDHR app). With the recording still "stuck" after using FF in the Roku v82 HDHR app, there's no way to restart playback at the very beginning of the recording, nor even to ever again get audio and video back on the screen. Totally broken.

----------------------------------------------------------------------

Here is a video of exactly the above scenario.

[DSperber]

From "newly discovered today"...

Roku v82 HDHR app FF function (and probably REW function as well, but I haven't tried that) appears to correctly skip forward 30-seconds and set the correct location pointer in INI/CFG for the recording. But it does not resume playback correctly after the 30-second skip-forward, instead just getting "stuck" with black screen presented.

If the Roku v82 HDHR app is then exited, and then relaunched, and then that "stuck" recording selected for playback and OK to presumably resume playback at the correct location, it again results in a black screen. Playback does not resume as expected.

But if I magically clear things up by instead using the ATV4K HDHR app to resume where the Roku HDHR app left off (i.e. 30-second skip forward location), which DOES resume at the correct 30-second skip-forward location, and then exit the ATV4K app, and then relaunch the Roku v82 HDHR app and try once again playing that recording, sure enough the Roku HDHR app now works perfectly! Play is properly resumed at the correct location of wherever the ATV4K app left off when it exited.

So it is a problem with Roku v82 HDHR app that makes it unable to resume normal audio/video playback once the 30-second skip-forward is performed via the FF button. The INI/CFG file data to record the new location seems to be good, as the ATV4K HDHR app can pick it up and resume at that correct location. It is only the Roku v82 HDHR app which does not resume at that correct location as must be properly stored in the INI/CFG file.

And using the ATV4K app to "clean house in the INI/CFG file", when it exits it leaves location information in a correct form that the re-launched Roku v82 HDHR app can now once again resume playback at that location, if playback of that recording is re-attempted.

-------------------------------------------------------------------------

Here is a video of the ATV4K HDHR app starting to play that recording, following having gotten "stuck" by the Roku v82 HDHR app by pushing FF.

[DSperber]

Not surprisingly, no response of any kind from SD. Despite the absolute courtroom-allowed video evidence of the multiple defects in v82 of the Roku HDHR app that I posted above, CRICKETS from SD. I would have at least expected some response, any response, acknowledging that the video proof is "interesting" at the very least. And then perhaps even offering to work with me to forward some type of forensic degug/diagnostic data that might help their developers figure out what's happening in my setup... BOTH OF THEM, which both fail identically.

I honestly have no urgent need to use the Roku version of HDHR app other than the fact that it is the one streaming device I own which supports locally decoded AC4 audio through both of my Ultra 4800's feeding AC3 5.1 to my two AVR's. That is my one and only motivation for wanting to use it, despite its desperately archaic and non-current user interface as compared to all other variants. It was almost abandoned by SD and left behind long ago, and is now only resurgent.

I can always use the LG HDHR app on my C7 and C9 instead of Roku, and also get locally decoded AC4 audio as well as SD's modern user interface. So it's not like Roku is critical to me.

Anyway, this lack of response to my problem report (especially since broken v82 playing recordings is just a brand new quick-fix for the broken v81 which absolutely crashed trying to even just get started playing recordings), is really a surprise. Given that the issues relate to "playing recordings" which was exactly what got broken in v81 with whatever was done there, and then theoretically got corrected (but obviously not really or entirely, or there is new breakage as a result of whatever was done in v82), I'm honestly surprised that "pride of authorship" wouldn't evoke some type of heightened interest in figuring out what is causing the behavior my videos demonstrate.

Oh well... looks like it's time to change directions radically, since my Flex 4K network tuner and client/server approach likely will not see the ability to view/record/playback NBC and CBS in LA (both of which are DRM protected) for a long time to come. I'm going to buy a "competitive product", albeit it can only connect to one of my TV's. But at least it CURRENTLY ALLOWS ME TO VIEW DRM CONTENT on that TV, with DVR/playback for DRM content expected within 1-2 months for the very next firmware upgrade, and then support for DRM content without a required internet connection on the target list for the next firmware upgrade after that.

Signed, an honestly disappointed long time customer, who is well aware and open to "early adopter" problems and willing to be very very tolerant, with reasonable response from the vendor.

[nickk]

We have confirmed the problem of the last few minutes of a recording playback repeating itself.
We have confirmed the problem of FF past the end of a recording playback resulting in a long delay, an error message, then not be able to return to the menu.
Both of these problems are understood and work started on them last week.

We have not been able to reproduce the pause problem you made a video of. Can you please provide a little more information... which model of Roku, what type of channel was recorded (ATSC 1, ATSC 3, cablecard, etc), what the audio path is (Roku straight to the TV via HDMI for example), etc.

Seek stalling - we think we know what the Roku player is unhappy about. We discussed the issue in our meeting last week and work will start this week.

I saw you sent me a PM. I was not available for much of last week.

[DSperber]

We have confirmed the problem of the last few minutes of a recording playback repeating itself.

This problem must have been reported by someone else, but that's still good that you have confirmed it and are working on it. My experimenting has never reached anything near the last few minutes of a recording.

We have confirmed the problem of FF past the end of a recording playback resulting in a long delay, an error message, then not be able to return to the menu.

Again, not my report. I have been unable to get FF -> PLAY to work at all. But the problem you describe seems to be related to starting FF and then simply letting it run without stopping, until it goes past the end of the recording. I never even experimented with such a scenario. But again, any problem reported by any user that you can confirm and then begin work on to fix... that's always a good thing.

The FF failures I reported are much more fundamental: IT DOESN'T WORK AT ALL!!! If a single press of FF is supposed to initiate a single 30-second skip forward and then audio+video resumess immediately but located 30-seconds in advance of where it was when FF was pressed, IT SIMPLY DOESN'T WORK! (see further comments at bottom)

We have not been able to reproduce the pause problem you made a video of. Can you please provide a little more information... which model of Roku, what type of channel was recorded (ATSC 1, ATSC 3, cablecard, etc), what the audio path is (Roku straight to the TV via HDMI for example), etc.

ALL OF MY TESTS WERE WITH TWO ROKU MODEL 4800, playing to LG OLED C7 and C9. I tried the same experiments with both setups, in order to confirm the problem.

The test recording was of one of the games of this recent World Series 2023, recorded from FOX KTTV NX, 105.1 here in LA. So it was ATSC 3.0. Actually I used this same recording for all of the reported issues for which I had made videos, but from a section maybe 15 minutes in from the beginning of the 4-hour recording.

HDHR DVR/server is running on a Win7 PC, although suspicious that this might be the culprit I also tried the tests running HDHR DVR/server on a Win10 PC. Made no difference. Same issues. Obviously caused by a Roku client problem, not the HDHR DVR/server.

HDMI Cabling is different on the two setups (but in NEITHER situation is the Roku plugged directly into the TV):

(1) Roku1 -> Smyth A16 Realiser (headphone processor) which processes audio and passes video-only out -> Yamaha RX-A1080 AVR, -> LG OLED C9.

(2) Roku2 -> HDMI 4-in-1-out switch -> HDMI external input of Oppo UDP-203 -> LG OLED C7

The pause problem is 100% reproducible in both setups. Just start playing a recording, and at some point press PAUSE to [theoretically] temporarily stop audio and video, freezing the video on the screen and stopping audio at the point of matching the frozen video.. During this state the audio continues to play, even though obviously it should not be continuing. The video remains frozen all during the ongoing audio.

Wait for a while before pressing PLAY to [theoretically] resume audio and video. The longer you wait the longer will be the ever-growing gap between still-frozen video and continuing audio which never stopped when PAUSE was pressed. And now press PLAY. Audio continues on, uninterrupted and at normal speed, from wherever it has by now reached (while video was still paused) when you now pushed PLAY to [theoretically] resume normal audio and video playback. As my video shows, video playback now starts up again but at a high-speed (looks like 2X or 3X or 4X?), which continues until the presented video "catches up" to wherever the still ongoing continuing normal-speed audio is. Once audio and video positioning are once more together, the high-speed video returns to normal 1X and once again is in sync with the audio.

THOUGHT: is the HDHR app even capable of 3X or 4X high-speed video playback? What is the high-speed when FF and REW onscreen of the non-Roku HDHR apps? In other words I believe the "catch-up" speed I describe above is much faster than just 2X. More like 3X or 4X. Perhaps that is coming from the underlying Roku Player itself because of commands given to it by the HDHR app, rather than from the HDHR app itself? Somehow the audio (continuing at normal speed and not paused as it should) is being treated separately from video (which is either paused or then playeed at high-speed 3X or 4X in order to catch up to video, after which the resume sync with each other. Would all of this point to Roku Player or HDHR app making this actually be possible?


As far as my FF issues, I'm going to post description of a new clue when I work out the whole scenario. But I think I had failed to appreciate that FF and REW were actually 30-second skip-forward and 15-second skip-backward. I had mentally thought these were the true "continuous" FF and REW functions (e.g. high-speed 2X, 3X, 4X) until PLAY was pushed to resume normal playback speed at wherever the new current location was, rather than simply "skips" forward or backward of some specific number of seconds. Of course the absence of a visible "time code" above the fuel gauge showing where the actual current position is would have been really helpful in clearing up my obvious misunderstanding.

I think the purple navigation right-arrow and left-arrow keys are probably supposed to the the "other half" of these two desired navigation methods. Either (a) fixed skip forward/backward some number of seconds for each press of the FF/REW keys, or (b) continuous high-speed 2X/3X/4X forward/reverse from one/two/three presses of purple navigation arrow keys... or the opposite assignment, whichever you choose. But BOTH capabilities really should ideally be available to the user.

Anyway, with this new understanding I've now retried my FF tests just by pressing FF once, rather than repeatedly, to see what actually happens. And sure enough if I do just that and wait paitently, within about 15 seconds the picture and sound will return. Seems like it might have been doing 2X internally, without presenting picture and sound so the screen is black and there is a fuel gauge displayed. I think my repeated presses of FF may have built up an accumulation of supposedly requested multiple 30-second skips. And if each skip was actually a 2X internal playback with black screenl for all this time, maybe that's why it seems like it never came back... because I lost patience. I hadn't realized I may have requested 2-4 minutes of "skip forward" and failed to realize it was only moving at 2X speed internally with black screen during that time. All very user-unfriendly.

Furthermore, I am now discovering that it seems possible to bring back playback after pressing BACK on the remote and then re-requesting playback of the recording using OK, maybe two of these recipes if necessary. This may be kind of numerology, in addition to using some other non-Roku HDHR app to "clean up the mess caused by FF on Roku" I can also do it on the Roku itself by "just being patient", and maybe also backing out of playback and coming back in... several times.

I will hold off any further thoughts on the FF issue, but as you already have confirmed there are many issues with FF on Roku v82. Not good.