Roku stuck on retrieving...again (updated)

[Movies32 0]

I attempted to play an episode of NCIS: Los Angeles tonight, but no matter what I did I could not get it to play.  Two nights ago it was working fine and I was able to play two episodes in a row, but now when I hit play on the episode it's stuck on "Retrieving".
 
I have a Roku 3 with the official Emby app (not Blue Neon Night) which is Version 3.0 & Build 97.  I am running the Emby server (Version 3.5.2.0) on my Windows 7 64-bit computer.

 

 

"NCIS: Los Angeles S9:E6 Can I Get a Witness?"

Log sent from Roku at 10:38PM (Eastern Time) on 9/14/2018 with user Josh.

 

 

I have hopefully attached all logs correctly.  Please let me know if you need any more information.  Thank you.

 

 

 

embyserver.txt

ffmpeg-remux-dd70082f-0cfd-4228-badd-ac0f6837c835.txt

Edited January 15, 2019 by Movies32

[Luke 37016]

Hi, what kind of drive is your H: drive?

[speechles 1917]

When you say it gets stuck at retrieving, you mean it gets stuck on the bar loading the video, correct? I've seen this before on a roku3 and it was on something with 1 refframe, although mine was 3.1 level.With 1 refframe I found some videos it stalls the progress of the buffering. It is something about the video the player doesn't like, and it makes it through the initial format detection routine (rokus internal mechanism to give errors). 

 

Would need a sample of the video to know for sure. If you use blue neon and "force transcode w/o stream copy" it should play the video just fine. It is only when direct stream copy the video this happens. It is with the older roku 2/3 hardware and everything before it. This is a tough one to  troubleshoot (since it happens inside the video player buffering, you might be able to tell buffering stall and force transcode without stream copy) or building the h264 profile more creatively for these older devices. Something along those lines.

Edited September 15, 2018 by speechles

[Movies32 0]

Hi, what kind of drive is your H: drive?

 

WD Black 2TB Performance Desktop Hard Disk Drive - 7200 RPM SATA 6 Gb/s 64MB Cache 3.5 Inch - WD2003FZEX

[Movies32 0]

When you say it gets stuck at retrieving, you mean it gets stuck on the bar loading the video, correct? I've seen this before on a roku3 and it was on something with 1 refframe, although mine was 3.1 level.With 1 refframe I found some videos it stalls the progress of the buffering. It is something about the video the player doesn't like, and it makes it through the initial format detection routine (rokus internal mechanism to give errors). 

 

Would need a sample of the video to know for sure. If you use blue neon and "force transcode w/o stream copy" it should play the video just fine. It is only when direct stream copy the video this happens. It is with the older roku 2/3 hardware and everything before it. This is a tough one to  troubleshoot (since it happens inside the video player buffering, you might be able to tell buffering stall and force transcode without stream copy) or building the h264 profile more creatively for these older devices. Something along those lines.

 

Yes it gets stuck on the bar loading the video.  I don't understand why it would play two episodes perfectly two days ago and now all of the sudden it won't play anything at all.  I've played similar videos to this prior and have not had any problems.  Maybe it's time for a Roku upgrade haha.

 

I just tried the "force transcode w/o stream copy" and it does the same thing.  The bar is about 1/4 of the way loaded and says retrieving.  I will attempt to try and play the video again tomorrow to see if anything changes because some days it decides to work and other days not.  Would the logs from a couple days ago help anything?  Although I wouldn't be able to send the log from the Roku, just the two that are on the server.

[speechles 1917]

Yes it gets stuck on the bar loading the video. I don't understand why it would play two episodes perfectly two days ago and now all of the sudden it won't play anything at all. I've played similar videos to this prior and have not had any problems. Maybe it's time for a Roku upgrade haha.

 

I just tried the "force transcode w/o stream copy" and it does the same thing. The bar is about 1/4 of the way loaded and says retrieving. I will attempt to try and play the video again tomorrow to see if anything changes because some days it decides to work and other days not. Would the logs from a couple days ago help anything? Although I wouldn't be able to send the log from the Roku, just the two that are on the server.

A sample of the video would help.

 

Ffmpeg -i file.ext -t 30 test-file.ext

 

Just a short sample of the video posted somewhere so it can be reproduced. Then it is easier to tell what next steps to take.

 

Sent from my Nexus 7 using Tapatalk

[Movies32 0]

A sample of the video would help.

 

Ffmpeg -i file.ext -t 30 test-file.ext

 

Just a short sample of the video posted somewhere so it can be reproduced. Then it is easier to tell what next steps to take.

 

Sent from my Nexus 7 using Tapatalk

 

What would be the best way to post a sample of the video?  The original video file size is 2.9GB.

Edited September 15, 2018 by Movies32

[ebr 14904]

WD Black 2TB Performance Desktop Hard Disk Drive - 7200 RPM SATA 6 Gb/s 64MB Cache 3.5 Inch - WD2003FZEX

 

Attached to the actual machine, correct?  i.e. not a mapped network drive.

[Movies32 0]

Attached to the actual machine, correct?  i.e. not a mapped network drive.

Yes. It is connected with a SATA cable.

[speechles 1917]

ffmpeg -i file.mkv -t 30 test-file.mkv  (mind you file and mkv are examples. Don't force mkv if your file is mp4, use the same extension)

 

This will have ffmpeg make a 30 second sample of your file. Copying everything. No mapping. This might break keyframes at the end, do weird things near the end, but we are concerned with the start so this is acceptable. The -t 30 tells it 30 seconds to trim. Then if you could upload that to dropbox, googledrive, etc.. We can use that sample to illustrate and develop a work-around, and provide to roku for their architect team who work on their product. Together, build a better product sort of thing. Sharing is caring.

Edited September 15, 2018 by speechles

[Movies32 0]

ffmpeg -i file.mkv -t 30 test-file.mkv  (mind you file and mkv are examples. Don't force mkv if your file is mp4, use the same extension)

 

This will have ffmpeg make a 30 second sample of your file. Copying everything. No mapping. This might break keyframes at the end, do weird things near the end, but we are concerned with the start so this is acceptable. The -t 30 tells it 30 seconds to trim. Then if you could upload that to dropbox, googledrive, etc.. We can use that sample to illustrate and develop a work-around, and provide to roku for their architect team who work on their product. Together, build a better product sort of thing. Sharing is caring.

Sorry, how do I do that first part exactly? I am technically inclined but not that much. Do I have to type this in somewhere to a certain program or something? Please advise. Thank you.

[speechles 1917]

Type this into your explorer bar, instead of a folder path, type this: %AppData%\Roaming\Emby-Server\ffmpeg

Now click into the newest dated folder. You should see ffmpeg and ffprobe in this folder.

 

Once in that folder, right click, choose new... text document. Now right click that text document it just made, choose open with... and pick notepad (wordpad may save in some weird format dont use it).. Then paste this: ffmpeg -i file.mkv -t 30 test-file.mkv

Save the file as trim.bat

 

Now copy your movie/video into that folder. After it copies, rename it to file.mkv. It is an MKV if I recall. After the rename, you can double click the trim.bat file. It should spawn ffmpeg and start operating. When it finishes there should be a test-file.mkv created in the same directory. This is the 30 second sample you can provide us.

Edited September 16, 2018 by speechles

[Movies32 0]

I get an error message if I try to navigate to that folder.  The first image is the error.  The second is what I have if I navigate to that folder myself.

 

 

 

 

 

 

[Happy2Play 8249]

That was a old path layout that changed awhile ago.  ffmpeg resides in system folder now.

 

%AppData%\Emby-Server\system

Edited September 18, 2018 by Happy2Play

[Movies32 0]

Here is the link to the video:    https://drive.google.com/file/d/1tnGAPOqtpBU23JDsEGBKFVDT0qsiaYvK/view?usp=sharing

 

So, will this fix the problem that I am having or do I have to figure out something else for watching my shows?

[speechles 1917]

 

Okay, on my roku ultra it plays just fine auto-detect mode in blue neon. Your sample is AVC with VORBIS. So, right on SCORE! Thats a nice combination to test with.

 

Cannot say for sure what the F is going on. AVC should play back on roku3. This is an mpeg4 avc and in that spec, officially they want 4.1 or 4.2. Now on the roku ultra which I am testing on 4.0 works just fine. Your video is 4.0. So maybe this has something to do with it? It might be the vorbis too. But if the profile matches how I've done it in blue neon, this works, otherwise.. blue neon wouldn't. Assuming the official app works like this, and it should, the issue might be the MKV with AVC.

 

ffmpeg -i test-file.mkv -t 30 test-file.mp4

 

If you do this, against the sample. Does the mp4 sample play with your roku3? Maybe it has to do with container?

 

If not we have to dig deeper why roku ultra plays it but roku3 cannot....

 

Can you also, turn on debug in the official beta app. After doing this press home on the remote. Restarting the app after turning on the debug makes the homescreen start up with a new debug button at the bottom. The app when closing the homescreen closes the app, so it is magic when you can reconfigure the homescreen without restarting the app. It is possible to do this magic, but requires a facade screen to support the extra screens on top, so the last screen never is closed. The app can eventually do that too and not require the restart. But after doing this restart, use the debug button to send logs from the app after attempting playback. Then ebr can see more than I can. With that maybe something pops up?

 

I no longer have a roku3 on site to test with, a friend borrowed it long ago, and never returned it. Same with the old roku2 DX. My buddy with that lives out of town. So all I have roku flavored now is the roku ultra.

 

@@ebr (nudge nudge poke poke)

Edited September 18, 2018 by speechles

[Movies32 0]

Apologies for the delay, but everything seems to be working fine at least for now.  Not sure what's going on.  I was able to play an episode on Wednesday night without problems and now tonight it is working fine again.  I will update if there are any more problems.

 

@speechless I will try and run your test if I have any more problems.

Edited September 29, 2018 by Movies32

[speechles 1917]

There are certain limitations in the app at the moment. Not saying it's incomplete. But there is still work to do on the profile to perfect the way this magic should happen. At a certain point, with some videos the logic can crash the app. The app asks for something the server hasn't given it yet. I am correcting this now and trying to get what I want to happen, but we know how that goes. You can only get there when it's there, you don't know you are there until you get there. This means, the app has to be able to work through video errors, errors in streams and gracefully recover. Without this and the video stopping with an error during playback destroys the magic. You know what is happening. This is the dispelling of the magic. You shouldn't have known there were errors and it should've kept trying. Part of that right now is missing. This is why the server isn't disclosing what the app expected to be there. I found a better way to make this magic happen so you can have your playback work through multiple playback errors. How many errors? That is the question. At what number does it get ridiculous?

 

Anyways.. suffice to say it is being worked on and it is an issue and I can replicate. I just need to work out one last minor hiccup.

 

Sent from my Nexus 7 using Tapatalk

Edited September 29, 2018 by speechles

[speechles 1917]

All the profile work is now complete and 100% device indepedent. Only information from your device is used to build the profile, nothing is assumed or hard-coded (except h264 for certain reasons - think fallback). This means the roku app will direct play, remux, direct stream far more than transcode. Checking your ffmpeg logs will show a vast improvement in direct support when falling back to recover playback, and it is quick to recover. Also added up to 10 errors capable of progressing through. Could've been higher but 10 is a nice good round number. There is still no force options. But believe me, the fallback mechanisms are doing this for you automatically. I want to finish tonight running more tests against the build using it as my nightly app tonight watching my shows. Once tomorrow gets here and I see no issues I will push everything to ebr and let him handle packaging. You all will be very happy with these changes. Be prepared to love your roku again.

Edited September 30, 2018 by speechles

[Movies32 0]

I attempted to play another episode tonight, but it didn't work.  I hit play on the episode and it took a few seconds to get through "retrieving" and actually played a second or two of video before getting stuck at "Loading" with the bar in the middle of the screen.  The bar went nowhere.  This time I used the Emby Beta app on the Roku.  I don't know if this information will help, but I will send it to you anyway.  Logs attached.

 

"NCIS: Los Angeles S9:E10 Forasteira"

Log sent from Roku at 10:14PM (Eastern Time) on 10/1/2018 with user Josh.

 

ffmpeg-remux-7b10946e-b966-4c52-aefb-7ec8874f2586.txt

embyserver.txt

Edited October 2, 2018 by Movies32

[speechles 1917]

I attempted to play another episode tonight, but it didn't work.  I hit play on the episode and it took a few seconds to get through "retrieving" and actually played a second or two of video before getting stuck at "Loading" with the bar in the middle of the screen.  The bar went nowhere.  This time I used the Emby Beta app on the Roku.  I don't know if this information will help, but I will send it to you anyway.  Logs attached.

 

"NCIS: Los Angeles S9:E10 Forasteira"

Log sent from Roku at 10:14PM (Eastern Time) on 10/1/2018 with user Josh.

 

This was LiveTV playback? Maybe this needs the same intervention as the other liveTV seeking issue.

 

I think it is that any errors in the video stream the Roku can, and might choke on. It is unpredictable, so many device models. Sometimes the fallback doesn't even get a chance to detect this, and the video player just stalls when this occurs. OTA liveTV might have.. well.. have errors.. sometimes alot. If it were instead transcoding the video stream instead of copying there is less chance of this causing the Roku to hang. I will look into this.. it is potentially the same as the cannot seek liveTV recordings in progress issue. Maybe liveTV needs this fix too to stop this issue? 

 

I did submit commits to allow this to work with liveTV recordings in progress, but not liveTV viewing. Maybe this needs a setting too? @@ebr thoughts?

 

Keep in mind, these changes were not intentional. This was done to give you the best playback fallback performance and minimize transcoding to the absolute minimum. Part of this impacts how liveTV is handled. In this cases, we can isolate liveTV (certain sections) as special cases and force some transcoding which will eliminate the errors altogether, eliminating the need for fallback to even occur.

Edited October 2, 2018 by speechles

[Movies32 0]

I just attempted to play the test file as an mp4 as you suggested @speechless and I'm still getting almost the same results.  I hit play on the episode and it was a little quicker to get through "retrieving".  It then played for a few seconds before getting to the "Loading" bar.  The "Loading" bar was almost full and then stopped for a few minutes with a tiny sliver left to fill before playing another second or two of video and stopping again.  It then went back to the "Loading" bar and took a few minutes for it to fill up and actually played the rest of the test video.  Logs are attached and sent from Emby Beta Roku app.  I hope this is all making sense.  If not, please let me know.


test-file.mp4 was the video I attempted to play.
Log sent from Roku at 10:47PM (Eastern Time) on 10/1/2018 with user Josh.

 

Here is the test video if needed:  https://drive.google.com/open?id=145jPtCikQZL0_VBb5ofPljEP9XSaPTcB

 

 

embyserver-63674031376.txt

ffmpeg-remux-c8e70a27-7496-4a6e-96bf-aac9997c667b.txt

ffmpeg-remux-f75c231e-a585-4d33-97b7-d19d589df827.txt

Edited October 2, 2018 by Movies32

[Movies32 0]

This was LiveTV playback? Maybe this needs the same intervention as the other liveTV seeking issue.

 

I think it is that any errors in the video stream the Roku can, and might choke on. It is unpredictable, so many device models. Sometimes the fallback doesn't even get a chance to detect this, and the video player just stalls when this occurs. OTA liveTV might have.. well.. have errors.. sometimes alot. If it were instead transcoding the video stream instead of copying there is less chance of this causing the Roku to hang. I will look into this.. it is potentially the same as the cannot seek liveTV recordings in progress issue. Maybe liveTV needs this fix too to stop this issue? 

 

I did submit commits to allow this to work with liveTV recordings in progress, but not liveTV viewing. Maybe this needs a setting too? @@ebr thoughts?

 

Keep in mind, these changes were not intentional. This was done to give you the best playback fallback performance and minimize transcoding to the absolute minimum. Part of this impacts how liveTV is handled. In this cases, we can isolate liveTV (certain sections) as special cases and force some transcoding which will eliminate the errors altogether, eliminating the need for fallback to even occur.

 

This was not LiveTV.  These videos are stored locally on my secondary internal HDD.

[Happy2Play 8249]

Why would Movies32 audiocodecs list like this?  Looks broken to me as mine don't appear this way.

AudioCodec=,aac,mp2,mp3,flac,opus,vorbis,lpcm

[speechles 1917]

Is it possible to share the file with me via PM?

 

The fallback routine if it sees a codec that should direct play has not been given authority to do a full transcode yet. It falls back through every way it can play directly but stumbles on the one in between. This is why I wanted to test the file myself and see if maybe I can reproduce or at least see a reason.

 

This was not LiveTV.  These videos are stored locally on my secondary internal HDD.

 

I might be confusing things, having moved from one topic to another. Apologies, but this will definitely tie into the same mechanisms used. I need to see where it fails in the fallback logic and what step needs to be skipped. If I had to guess, it is the fact that right now.. h264 always copies, never really fully transcodes. I can adjust this in the fallback, I just needed to see a reason why as my samples didn't give me a good reason to add cost to playback unless it is deserved. Transcoding anything comes with cost. To use it for any situation drives up the expense for every user and slows their PC down for no reason. My intent is to provide you with the best playback in the most efficient way.

 

These files have errors in them is the reason they don't play. Something the Roku doesn't like. In this case, it is the Audio, so it starts off in what is known as transcode mode already. It is this fallback missing the last piece of the puzzle, which I just found below. Keep reading..

 

 

Why would Movies32 audiocodecs list like this?  Looks broken to me as mine don't appear this way.

AudioCodec=,aac,mp2,mp3,flac,opus,vorbis,lpcm

 

Typo on my part. But it taught me if I give a blank audio codec at start, I can use that to disallow all codecs in the list from copying, force them to transcode, and it transcodes to the 2nd codec in the list. The first codec is preferred to use as the transcode codec. In the absense and because it is blank this must throw the logic of the server off and it transcodes to the second codec in the list. Score! Nice...This is handy and very useful. I can use this to fix an issue I have been having with full transcoding, and h264 being transcoded to h264, but instead It always copies. This may offer the last puzzle piece and a way to do this with a cheap cost and effort.

Edited October 2, 2018 by speechles