Jump to content

2 Rokus Buffer, 1 Doesn't


snodrog742

Recommended Posts

snodrog742

You can also, use the transcoding-temp folder to see what is going on. Reproduce the issue on the roku and pause right after it happens. In the servers transcoding-temp folder are the m3u8 and ts slices the roku was fed. Therein lies the answer.

 

NOTE: make sure to just pause on the roku and not to stop, or press back as these will tell the server playback stopped and it will dispose of the temp files.

I didn't see an m3u8 but the .ts file didn't skip like on the Roku.  The skipping on Roku does occur though where one .ts file ends and where another begins like they're not stitching together properly.

 

It depends.  If the video was transcoding, then yep, I'd be interested in that.  If it was just transcoding the audio and copying the video, then it's the same situation that I'm investigating now.

 

It was audio only so seems to be same issue.

 

Are we any closer to fixing this issue?  I feel like we've got lots of information but no real solution.

Link to comment
Share on other sites

Waldonnis

Are we any closer to fixing this issue?  I feel like we've got lots of information but no real solution.

 

I have eliminated some potential causes, but haven't found anything that would indicate a probable cause quite yet.  Interesting that you mention the skipping seeming to occur at segment boundaries, though.  That may mean something and I can post shortly explaining why that may be relevant.  But first, let's see if there's a way to eliminate that potential cause without having to barrage you with a babble-rific explanation of frame types and segmenting....

 

@@speechles   I can't test this at the moment, so I figured you'd be the person to ask...

I noticed Emby's official channel is enabling break_non_keyframes (by adding BreakOnNonKeyFrames=True to the server request) while a "force transcode" remux using BNN does not.  Would BNN's behaviour change in that regard for audio-only transcode scenarios?  If BNN never "enables" breaking on non-keyframes as part of the server interaction, @@snodrog742 may be able to sideload BNN and see if the same behaviour happens when segments actually start with keyframes.

Edited by Waldonnis
Link to comment
Share on other sites

snodrog742

 

I have eliminated some potential causes, but haven't found anything that would indicate a probable cause quite yet.  Interesting that you mention the skipping seeming to occur at segment boundaries, though.  That may mean something and I can post shortly explaining why that may be relevant.  But first, let's see if there's a way to eliminate that potential cause without having to barrage you with a babble-rific explanation of frame types and segmenting....

 

@@speechles   I can't test this at the moment, so I figured you'd be the person to ask...

I noticed Emby's official channel is enabling break_non_keyframes (by adding BreakOnNonKeyFrames=True to the server request) while a "force transcode" remux using BNN does not.  Would BNN's behaviour change in that regard for audio-only transcode scenarios?  If BNN never "enables" breaking on non-keyframes as part of the server interaction, @@snodrog742 may be able to sideload BNN and see if the same behaviour happens when segments actually start with keyframes.

 

BNN actually never plays the movie (Ready Player One) or The Last Man Standing episode you have.  I've tried Force Transcode and all and never even starts after waiting up to 20 minutes.  If I force Direct Play they will play but with no audio.

Link to comment
Share on other sites

Waldonnis

BNN actually never plays the movie (Ready Player One) or The Last Man Standing episode you have.  I've tried Force Transcode and all and never even starts after waiting up to 20 minutes.  If I force Direct Play they will play but with no audio.

 

:blink:   Now that's wacky.  I would expect Direct Play to not have audio, since it looks like your setup can't decode AC3 natively, but auto should be working and transcoding the audio as one would expect.  It doesn't do things much differently than the official client does, so I'm not sure why it would have a different result during normal playback.  My setup actually does decode AC3 natively, so it's been harder for me to test that way.  I made a version with DTS audio instead to force the same type of operation since my television doesn't decode DTS  :P   Let's see what he says, though...if BNN never enables segmenting on non-keyframes, figuring out what's going on with BNN playback would be worth it so that we can test if that the segmenting method is causing the main issue.

Link to comment
Share on other sites

Waldonnis

Welcome to my life...

 

I'm the same way.  That old saying "better to have bad luck than no luck at all"...my friends all say to me, "If that's true, I'd rather have no luck than YOUR luck."  It's partially why I'm so pedantic about my media library and how I encode - when it's all carefully/consistently encoded and uses the same container and track arrangements, there's little room for anything to go wrong.

Link to comment
Share on other sites

:blink:   Now that's wacky.  I would expect Direct Play to not have audio, since it looks like your setup can't decode AC3 natively, but auto should be working and transcoding the audio as one would expect.  It doesn't do things much differently than the official client does, so I'm not sure why it would have a different result during normal playback.  My setup actually does decode AC3 natively, so it's been harder for me to test that way.  I made a version with DTS audio instead to force the same type of operation since my television doesn't decode DTS  :P   Let's see what he says, though...if BNN never enables segmenting on non-keyframes, figuring out what's going on with BNN playback would be worth it so that we can test if that the segmenting method is causing the main issue.

 

https://github.com/speechles/BN-ONE

 

There is the repository, and I even updated it to match the latest v4.26 copy. Inside the GeneralMetadata, VideoMetadata, and VideoPlayer scripts are the code you are after. I can't really update the store link anymore, so anyone wanting the app has to sideload. Having it hosted locally on my own site, didn't allow easy browsing of the source code. Now the easy browsing of the source code is available. Have at it. :)

 

I'm the same way.  That old saying "better to have bad luck than no luck at all"...my friends all say to me, "If that's true, I'd rather have no luck than YOUR luck."  It's partially why I'm so pedantic about my media library and how I encode - when it's all carefully/consistently encoded and uses the same container and track arrangements, there's little room for anything to go wrong.

 

Been down since I began to crawl... ohhh.. If it wasn't for bad luck, you know I wouldn't have no luck at all..

 

 

As Jay-Z once said, and to larger extent the main character of Annie - "It's a hard knock life, for me!"

Edited by speechles
Link to comment
Share on other sites

@@speechles any idea why BNN won't play stuff for me?

 

Possibly. In fact, the store version (aka v4.25) of BNN, isn't capable of stream copy. This is because back when I added that ability emby server wasn't giving enough context to the app. So I used the "name" attribute as a cheaper way to read the codec information than going after the streams themselves (i wanted to avoid a 2nd fetch). This worked, but I should've really just grabbed the info from the streams(I shouldve done the 2nd fetch anyways).

 

23.976/1040P/H264/AAC / Played 2x / Last 2018-07-13 at 4:08pm

 

The 1040p/h264/aac used to be what emby would give as the attribute "name" in the json object. Well now, name is actually the name and the store version is stuck now and can't be updated. The 4.26 version now gets the information from the streams themselves (does the 2nd fetch), and will properly stream copy when it can instead of doing a full transcode.\

 

Also, keep in mind the BNN has "Force Transcode" and "Force Transcode w/o Stream Copy". When you say you "Force Transcode" I assume you mean with stream copy, not w/o and it should do a remux of the video stream when it can (if your capabilities support it the app checks for) and "Use Auto-Detection" should work just fine.

 

tl;dr: You are using (v4.25 aka not sideloading v4.26) and it is doing a full transcode instead of stream copying the video.

Edited by speechles
Link to comment
Share on other sites

snodrog742

Possibly. In fact, the store version (aka v4.25) of BNN, isn't capable of stream copy anything except.. h264. This is because back when I added that ability emby server wasn't giving enough context to the app. So I used the "name" attribute as a cheaper way to read the codec information than going after the streams themselves. This worked, but I should've really just grabbed the info from the streams. This is the 23.976/1040P/H264/AAC / Played 2x / Last 2018-07-13 at 4:08pm part. The 1040p/h264/aac used to be what emby would give as the attribute "name" in the json object. Well now, name is actually the name and the store version is stuck now and can't be updated. The v4.26 version now gets the information from the streams themselves, and can properly stream copy when it can instead of full transcode.

 

tl;dr: You are using (v4.26 aka not sideloading the app) and it is doing a full transcode instead of stream copying the video.

 

I should've saved you from typing all that.... I did sideload.  Sorry!

Link to comment
Share on other sites

Did you change any of the preferences from their default in the app?

 

First choose "Use Auto-Detection" just to make sure nothing fishy is going on and mysteriously now things just work.

 

Then choose "Force Transcode" and see if it plays. After choose "Force Transcode w/o Stream Copy" and see.

 

NOTE: Do not back out when playing unless it just seems to hang for more than 5 minutes. The app should time out the sessions eventually and respawn a fallback attempt. Then it should give a clear message the video failed to play and give you the next action to take (which should be to report the video on emby forums). If the video loading screen hangs, the app can't self detect the video failed. There is no way roku gives for an app to detect that hang, so only at these times should you press back to get out of the waiting.

 

One of those ways should work. Does one of em?

 

And the "w/o stream copy" way is actually reducing the bitrate the app thinks you request to 1 below the bitrate of the video stream itself. This tricks the server into doing a full transcode of the video rather than copy. This saves you from having to set the bitrate lower than video to get it to "force transcoding" like you do in official apps.

Edited by speechles
Link to comment
Share on other sites

snodrog742

Did you change any of the preferences from their default in the app?

 

First choose "Use Auto-Detection" just to make sure nothing fishy is going on and mysteriously now things just work.

 

Then choose "Force Transcode" and see if it plays. After choose "Force Transcode w/o Stream Copy" and see.

 

NOTE: Do not back out when playing unless it just seems to hang for more than 5 minutes. The app should time out the sessions eventually and respawn a fallback attempt. Then it should give a clear message the video failed to play and give you the next action to take (which should be to report the video on emby forums). If the video loading screen hangs, the app can't self detect the video failed. There is no way roku gives for an app to detect that hang, so only at these times should you press back to get out of the waiting.

 

One of those ways should work. Does one of em?

 

And the "w/o stream copy" way is actually reducing the bitrate the app thinks you request to 1 below the bitrate of the video stream itself. This tricks the server into doing a full transcode of the video rather than copy. This saves you from having to set the bitrate lower than video to get it to "force transcoding" like you do in official apps.

 

No, did not change settings that I know of.  Would side loading again reset everything?  I can retry these to be sure but none of the options played and hung for longer than 5 minutes with no messages.  Is 5 minutes the longest I should wait per attempt?

Link to comment
Share on other sites

No, did not change settings that I know of.  Would side loading again reset everything?  I can retry these to be sure but none of the options played and hung for longer than 5 minutes with no messages.  Is 5 minutes the longest I should wait per attempt?

 

No, to clear settings choose "sign out" and on the user select screen is a little garbage can. This will wipe the registry for the app. Then press home to bail out of the app at that point. Now start it again, and it should act like you just installed it.

 

There is a setting in the app, called "Videoplayer Timeout" that controls how long the app waits before it assumes it can't get the next segment and bails.

 

The problem is, when the video hasn't completely loaded yet, and is in the "retreiving..." state and the bar starts to fill and stops part way then never continues. This is actually the roku firmware failing to detect the video support correctly. Roku has its own internal video detection routine that runs after the video has buffered 30% (not 30% of the file, 30% of its buffer has filled and it knows at that point it has enough data) or so where it can make judgements on what the data contains so it can guess what video type it is getting. In turn it can tell the GPU what to expect since the app has no control over that part of the communications. The issue happens because that video detection routine can also... crash or hang. Now the video player is stuck, and the app is waiting for the core videoplayer function to return control back to it to signal the video failed, so it can attempt a fallback or a give a diagnoses dialog to the user. When this occurs the app never gets a signal anything since the videoplayer is stuck waiting on the video detection firmware function and we never get beyond 30% and it just stays there all day and on (you can wait forever and it will still hang longer than forever, infinity+1) and there is little you can do except press back to exit the video player.

 

If using full default settings in the app, this should never occur. Especially when you change among the three different kinds of play methods the app has. One of more of those methods should play the item. This is the entire purpose of the blue neon app is to debug situations like this which is when at that point we can start to change preferences to get around it.

Edited by speechles
Link to comment
Share on other sites

snodrog742

No, to clear settings choose "sign out" and on the user select screen is a little garbage can. This will wipe the registry for the app. Then press home to bail out of the app at that point. Now start it again, and it should act like you just installed it.

 

There is a setting in the app, called "Videoplayer Timeout" that controls how long the app waits before it assumes it can't get the next segment and bails.

 

The problem is, when the video hasn't completely loaded yet, and is in the "retreiving..." state and the bar starts to fill and stops part way then never continues. This is actually the roku firmware failing to detect the video support correctly. Roku has its own internal video detection routine that runs after the video has buffered 30% or so where it can make judgements on what the header contains so it can guess what video type it is getting. In turn it can tell the GPU what to expect since the app has no control over that part of the communications. The issue happens because that video detection routine can also... crash or hang. Now the video player is stuck, and the app is waiting for the core function to return control back to it to signal the video failed, so it can attempt a fallback or a give a diagnoses dialog to the user. When this occurs the app never gets a signal anything is wrong so time just becomes infinite (you can wait forever and it will still hang longer than forever, infinity+1) and there is little you can do except press back to exit the video player.

 

If using full default settings in the app, this should never occur. Especially when you change among the three different kinds of play methods the app has. One of more of those methods should play the item. This is the entire purpose of the blue neon app is to debug situations like this which is when at that point we can start to change preferences to get around it.

 

Thanks for the details.  Much like Rarflix, I figured BNN was much the same.  I will reset it just to be safe (because my memory sucks) and report back.

Link to comment
Share on other sites

snodrog742

No, to clear settings choose "sign out" and on the user select screen is a little garbage can. This will wipe the registry for the app. Then press home to bail out of the app at that point. Now start it again, and it should act like you just installed it.

 

There is a setting in the app, called "Videoplayer Timeout" that controls how long the app waits before it assumes it can't get the next segment and bails.

 

The problem is, when the video hasn't completely loaded yet, and is in the "retreiving..." state and the bar starts to fill and stops part way then never continues. This is actually the roku firmware failing to detect the video support correctly. Roku has its own internal video detection routine that runs after the video has buffered 30% (not 30% of the file, 30% of its buffer has filled and it knows at that point it has enough data) or so where it can make judgements on what the data contains so it can guess what video type it is getting. In turn it can tell the GPU what to expect since the app has no control over that part of the communications. The issue happens because that video detection routine can also... crash or hang. Now the video player is stuck, and the app is waiting for the core videoplayer function to return control back to it to signal the video failed, so it can attempt a fallback or a give a diagnoses dialog to the user. When this occurs the app never gets a signal anything since the videoplayer is stuck waiting on the video detection firmware function and we never get beyond 30% and it just stays there all day and on (you can wait forever and it will still hang longer than forever, infinity+1) and there is little you can do except press back to exit the video player.

 

If using full default settings in the app, this should never occur. Especially when you change among the three different kinds of play methods the app has. One of more of those methods should play the item. This is the entire purpose of the blue neon app is to debug situations like this which is when at that point we can start to change preferences to get around it.

No options but Direct Play work after leaving 5 mins each

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

@@snodrog742

 

roger no options selected, all default.. perfect for testing.

...but you say, direct play works after leaving for 5 minutes? I want to follow up on this and figure out the issue here, but not quite understanding.. you choose "force direct"?... or is this with "auto-detection"? if Is, is "auto-detection" using direct stream or transcoding?

 

Did you turn on "enable debug" in the app, and then use the "show debug logs" on the options row that appears to see what happens? Might not have known that existed. So turn it on and then load the video, then let it fail and just hang. Now go to the "debug logs" right after and view the logs. You might have to scroll for awhile. But you can see the url it is attempt to play when it does, which codecs on your roku were detected, and how the app chose to play your item..and after this is the output from the roku. It starts with ::roVideoScreenEvent - VideoStatus: 0 0 and below this look for more ::roVideoScreenEvent messages. Are there any unknown events shown? Do any of these say "format detected"?

 

Lastly, do you have a way to share the file with me so I can do some tests?

Edited by speechles
Link to comment
Share on other sites

snodrog742

@@snodrog742

 

roger no options selected, all default.. perfect for testing.

...but you say, direct play works after leaving for 5 minutes? I want to follow up on this and figure out the issue here, but not quite understanding.. you choose "force direct"?... or is this with "auto-detection"? if Is, is "auto-detection" using direct stream or transcoding?

 

Direct Play works instantly but no audio.  Have to choose Force Direct Play though.  Auto-detection goes to direct stream.

 

 

Did you turn on "enable debug" in the app, and then use the "show debug logs" on the options row that appears to see what happens? Might not have known that existed. So turn it on and then load the video, then let it fail and just hang. Now go to the "debug logs" right after and view the logs. You might have to scroll for awhile. But you can see the url it is attempt to play when it does, which codecs on your roku were detected, and how the app chose to play your item..and after this is the output from the roku. It starts with ::roVideoScreenEvent - VideoStatus: 0 0 and below this look for more ::roVideoScreenEvent messages. Are there any unknown events shown? Do any of these say "format detected"?

 

Did not turn this on.  Just to be clear, it never ever loads and sticks at Retrieving... and technically never fails. Should I still do this?

 

 

Lastly, do you have a way to share the file with me so I can do some tests?

 

Yea but is a large file.  Let me see what I can do.

Link to comment
Share on other sites

Okay, so since you have to force direct, the app knows your setup cant support the audio. Direct play silence makes sense.

 

And yes, enable debug and look at the debug logs button on the options row after you have the video fail. The ::rovideoplayer unknown events I am interested in as these are the firmware detection routines.

 

it isn't necessary I get the file in full. Just a sample cut of the first couple minutes would be enough: ffmpeg -i video.mkv -ss 0 -t 120 sample.mkv

Edited by speechles
Link to comment
Share on other sites

snodrog742

@@snodrog742

 

Did you turn on "enable debug" in the app, and then use the "show debug logs" on the options row that appears to see what happens? Might not have known that existed. So turn it on and then load the video, then let it fail and just hang. Now go to the "debug logs" right after and view the logs. You might have to scroll for awhile. But you can see the url it is attempt to play when it does, which codecs on your roku were detected, and how the app chose to play your item..and after this is the output from the roku. It starts with ::roVideoScreenEvent - VideoStatus: 0 0 and below this look for more ::roVideoScreenEvent messages. Are there any unknown events shown? Do any of these say "format detected"?

Edited.

 

 

None say “format detected”

 

 

Sent from my iPhone using Tapatalk

Edited by snodrog742
Link to comment
Share on other sites

None say “format detected”

 

 

 
(2nd picture) Unknown Event 33, msg: Format Detected
 
It hangs at 999 (VideoStatus: 999 0 .. repeats), which it needs 1000 to begin playing. So this is definitely something related to the video core in the firmware. You can see the other unknown events for the segments downloading and that means that indeed the HLS (.ts) packets are making their way into the app.
 
I also see you sent me a link to the file to test in pm. Will try that in 4 hours after it downloads (i gots slow internets..lol).
 
It does possibly look like the "srt" subtitle stream might be hanging it, but would be nice to know 100% what it is.
 
EDIT: For shits-n-giggles, can you try again, only this time first use the audio & subtitles menu? Make sure subtitles are set to none. Then hit play again and see if it now works. If it does I have an idea of what is happening, your srt subtitles are being served in the m3u8 via ssl, and this app uses the old roVideoPlayer which might freak out when handed something like that. Not entirely sure, but changing subtitles to none prior to play should help eliminate this as a cause.
Edited by speechles
Link to comment
Share on other sites

snodrog742

(2nd picture) Unknown Event 33, msg: Format Detected

 

This is why you never trust the one who has no clue what he's doing half the time...

Link to comment
Share on other sites

@@snodrog742 Thanks for the help. You need to edit your post, and can delete the 2 pictures now. No sense having others use the information for evil.

 

 

Okay, now the results. I Tested all play methods on my roku ultra:

 

1) auto-detection (which allows DD+ in my case): same as using force direct as this direct plays for me. plays fine.

2) auto-detection PRIVATE (which forces only stereo): same as force transcode, converts the ac3 audio to aac. slight delay, but plays fine.

3) force direct: works, using * can change among all subrips perfectly and roku ultra displays these fine.

4) force transcode: works, but only copies the video stream if none is selected as subtitle.

5) force transcode w/o stream copy: works, but.. if a subtitle stream is chosen the server burns these in when the roku supports subrip directly. I need to update the apps capabilities.

 

So the problem appears to be emby server is burning in subrip subtitles when it doesn't need to. The roku models (all of them??!) can support this natively (at least my ultra does) during direct play and can change subtitles using * among all the subrips just fine. It is when using audio & subtitles menu and choosing a subrip prior to play that things go wrong as the server burns them in. Need to fix that.

 


 

Fixed it, hopefully... *crosses fingers*

 

Here is the new BNN zip:


 

Can someone test this new build with subrip subtitles both internal and external with the roku 2/3 models and verify this indeed does work. Thanks.

Edited by speechles
Link to comment
Share on other sites

Waldonnis

4) force transcode: works, but only copies the video stream if none is selected as subtitle.

 

This is pretty much what I want to see what happens with (did that make sense?).  I really just want to see if segmenting on keyframes will make a difference: if the "skipping" stops happening when doing that.

 

I didn't see anything in the repo that added BreakOnNonKeyFrames to the request string.  Thus, I'm assuming that, unless it's explicitly sent/set to true, Emby's default would be "false" since I've never seen the value as "true" in the server logs when remuxing video via BNN.  I just wanted to confirm that it wasn't being explicitly sent/set by BNN (basically, that the param was never added to the query string sent to the server).

 

Sorry for the few-days delay.  I've been trying to diagnose some decoding errors in some HEVC files that I'm working on, which took a lot of back-and-forth between the spec, ffmpeg parser code, and the bitstream analyser (read: boring and frustrating, but at least I learned something).

Link to comment
Share on other sites

You are assuming correct. The server is return the playback url to the app. The server is adding those parameter fields to the url.. but.. I can make it easier for you to check what you need.

 

I'll hack the app to support what you want.. brb

 

EDIT

 

https://github.com/speechles/BN-ONE/commit/3414b12f267187e41669da3e7b4492cd40190aef

 

Now it's done properly before the video player is created. Works. Now you can run your tests with this zip:

https://github.com/speechles/BN-ONE/files/2207375/emby.blue.neon.v.4.28.zip

 

Look in preferences near the top for the new option. Would be equally easy to shovel other attribute changes in there too with options to turn em on and off. Let me know if this lets you find out what you want to find out. :^)

 

 

EDIT2:

 

..and it looks like that repeating at the end can be stopped by using it indeed.

 

Steps to replicate using BNN v4.28:

 

1) Navigate in app to any video that is encoded with h264 (audio codec doesn't matter)

2) Change play method to "Force Transcode"

3) Choose play from scene, move all the way to the right to the last scene and play

4) Wait..  and the last few bits at end will repeat randomly with audio not matching... after it will go back to the video detail screen.

5) Choose "more ..." and  choose "-> Go To ..." and choose "Go To Preferences" and change the BreakOnNonKeyFrames to true

6) Back out of preferences to return to the same video detail screen.

7) Change play method to "Force Transcode" again (make sure it still says "Force Transcode")

8) Choose play from scene again, and again move all the way to the right to the last scene and play

9) Wait... but...This time it actually ends when it ends, and nothing seems peculiar.

10) Chug a beer and imagine high-fiving Waldonnis for fixing it.. sweet.. dude.. sweet.. dude

 

I think we have a winner! *rings bell*

 

@@Waldonnis Good Work, Gumshoe!

Edited by speechles
Link to comment
Share on other sites

Waldonnis

*fingers crossed*  Let's hope it's the segmenting.  If not, I have to look at the bitstream and segments again  :P

 

Funny thing is, the HLS spec doesn't require that segments start with keyframes, but it's usually encouraged since adaptive streaming (stuff like Netflix or other CDNs) would need it any way.  For stuff like webcam streams or situations where there are no variants (like Emby), then it shouldn't technically matter...although devices/browsers/OSes may not follow the letter of the spec that way (they may have decided to read "should" as "must").  It would be interesting (and useful) to know if Rokus are pickier in that regard, and it wouldn't surprise me if they are since they're mostly designed around CDN-provided streams.

 

Side note: Roku pushed out an OS update recently to at least the RokuTV platforms (unsure if STBs got one yet, or which ones), so it may be worth checking it out after updating as well (means I also have to do my usual "let's see what previously fixed bugs are unfixed" regression tests yet again soon).

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...