Trouble Playing Transcoded Content

[speechles 1920]

The .bif is a red herring. These wouldnt stop the entire transcode. If they arent present you would see placeholder images when rewind/fastfwd. What is happening to you is causing ffmpeg to never spawn when requested from the roku. This is clear by the timeout the roku is giving. It is something to do with ffmpeg and permissions/paths.

 

Where is your transcode directory? Does the emby user(ffmpeg process) have access to read, write, and execute(navigate subdirs) for it?

 

Sent from my Nexus 7 using Tapatalk

[Happy2Play 8293]

@@speechles

 

Emby validated ffmpeg, could this be a version issue?

2017-01-08 13:43:41.0123 Info MediaEncoder: FFMpeg: /usr/local/bin/ffmpeg
2017-01-08 13:43:41.0123 Info MediaEncoder: FFProbe: /usr/local/bin/ffprobe
2017-01-08 13:43:41.0123 Info MediaEncoder: Validating media encoder at /usr/local/bin/ffmpeg
2017-01-08 13:43:41.0174 Info MediaEncoder: Running /usr/local/bin/ffmpeg -decoders
2017-01-08 13:43:41.2510 Info MediaEncoder: Running /usr/local/bin/ffmpeg -encoders
2017-01-08 13:43:41.3642 Info MediaEncoder: Encoder available: libx264
2017-01-08 13:43:41.3655 Info MediaEncoder: Encoder available: libx265
2017-01-08 13:43:41.3682 Info MediaEncoder: Encoder available: mpeg4
2017-01-08 13:43:41.3697 Info MediaEncoder: Encoder available: msmpeg4
2017-01-08 13:43:41.3723 Info MediaEncoder: Encoder available: libvpx
2017-01-08 13:43:41.3752 Info MediaEncoder: Encoder available: libvpx-vp9
2017-01-08 13:43:41.3781 Info MediaEncoder: Encoder available: aac
2017-01-08 13:43:41.3837 Info MediaEncoder: Encoder available: libmp3lame
2017-01-08 13:43:41.3905 Info MediaEncoder: Encoder available: libopus
2017-01-08 13:43:41.3950 Info MediaEncoder: Encoder available: libvorbis
2017-01-08 13:43:41.3999 Info MediaEncoder: Encoder available: srt
2017-01-08 13:43:41.4160 Info MediaEncoder: Encoder available: h264_vaapi
2017-01-08 13:43:41.4195 Info MediaEncoder: Encoder validation complete

[speechles 1920]

 

 

@@speechles

 

Emby validated ffmpeg, could this be a version issue?

If emby validated it that means it has to be the temporary transcode location. The emby users ffmpeg process needs the ability to write to it. This is why no transcode logs are created, but ffmpeg exists.

 

 

 

Sent from my Nexus 7 using Tapatalk

[Luke 37092]

@@de0x3 are you able to play content using the Emby web app?

[de0x3 0]

Where is your transcode directory? Does the emby user(ffmpeg process) have access to read, write, and execute(navigate subdirs) for it?\

 

I haven't changed the transcoding path from the default which is: /var/db/emby-server/transcoding-temp.  The permissions on this path are:

root@emby_test:/var/db/emby-server # ls -lah | grep 'transcoding-temp'
drwxr-xr-x   2 emby  emby    716B Jan  8 22:47 transcoding-temp

@@Luke

Yes, I was just now able to play this movie via the web app (Chrome).  The attempted playback resulted in the creation of a remux log.

[Luke 37092]

Is this an issue on the new Roku app?

[de0x3 0]

Good day Luke,

 

Yes, this issue also presented itself while testing the new Roku app.

 

Thanks!

[de0x3 0]

Hello All,

 

I hope everyone is well.  I wanted to note that I've compiled Emby on another system which has more resources to try and rule out any issue that might be due to lack of CPU cores, or other hardware.  Unfortunately, I received the same result of a timed out connection.  Taking a PCAP of the network traffic doesn't yield anything either.  I'm able to observe the Roku requesting the .m3u8 link, and shortly thereafter the Roku issuing a POST to /emby/Sessions/Playing/Stopped; very shortly in fact, as the capture shows just .6s between the issued GET to main.m3u8 and the POST.  Interestingly, 3.1s after the GET to main.m3u8 data begins.  Following the TCP stream in Wireshark shows the attached.

 

.6s seems short, am I looking at this correctly?

 

Thanks!

 

EDIT: Forgot to attach file.

emby-server-pcap-tcp_stream.txt

Edited January 20, 2017 by de0x3

[Luke 37092]

It's normal. the manifest is just text and very quick. The thing that needs to be figured out is why is the Roku aborting at that point instead of proceeding to start downloading the .ts segments listed in the manifest.

 

I think the only way to find out will be debugging video player error messages from within the Roku app. Basically it appears that it sees something it doesn't like and decides not to proceed.

[speechles 1920]

Like luke said, you can use the roku logs to see why the videoplayer aborts. Enable debug in the blue neon app. Now reproduce the issue. Then go to the options row on the homescreen and look for the debug logs button. In this should be ::rovideoscreenevent messages. One of these messages will be from an isRequestFailed. It should tell you why it aborted the video player in these logs.

 

Edit:

Well snap.. haw.. you already did this and this is how you know its a timeout.. nice. So disregard the big paragraph above and lets move deeper.

 

I know of an issue affecting level 31 in h264. I can reproduce it over and over, anything with level 31 and 4 refframes wont play in direct stream. It hangs the player maxed out at 100% buffer. All other refframes in my tests worked, 1-3, 5-16. Now the fun fact part, if I attempt to transcode this, there is no audio even though is says there is. The video plays but there is silence no matter how I attempt to change the audio codec. So there is an issue with level31 stuff that I know of, but that was the only edge case I could find.

 

My roku3 is on the exact same firmware you are on. Is there some way you can put that file on dropbox or similar, and share via pm with speechles and ebr. This way you dont need to be the sounding board and we bounce ideas off you. We can directly experience the issue ourselves. I am on windows, if your file has no ill effects for me and we share the sa e emby server version this means OS/ffmpeg is the issue. If I suffer the same problem, this means rokus firware is.

 

Apologies for the issue, hopefully after trying the file directly ourselves we can point fingers in the right direction and get your issue resolved.

Edited January 20, 2017 by speechles

[de0x3 0]

Hello All,

 

Thank you to everyone that has been helping thus far!  I really appreciate all the support on this.

 

My roku3 is on the exact same firmware you are on. Is there some way you can put that file on dropbox or similar, and share via pm with speechles and ebr. This way you dont need to be the sounding board and we bounce ideas off you. We can directly experience the issue ourselves. I am on windows, if your file has no ill effects for me and we share the sa e emby server version this means OS/ffmpeg is the issue. If I suffer the same problem, this means rokus firware is.

 

Thank you for your help!  Are there any other options that we can explore for me to gather data for you?  I'm fairly comfortable with technology and wouldn't mind diving into this problem using whatever debugging tools you could equip me with.  I'm hesitant to pass along the movie in question as it's copyrighted material.

 

Also, I seem to have stumbled on to another odd piece to the puzzle and perhaps it's my own misunderstanding of what is going on when a movie is required to be transcoded.  If I connect my Roku2 via a wired Ethernet connection, the movie transcodes correctly, and streams almost instantly.  If I move back to a wireless connection the Roku gives up before starting to play the content.  I've verified a number of items related to connectivity and have reviewed numerous packet captures taken at various points through the path.  I cannot seem to find anything network related that would be to blame.  Is there any tool on the Roku itself that might be able to help me understand what the difference would be (or that would generate enough logs for me to pass on)?

 

Thank you all very much!

de0x3

[speechles 1920]

Hello All,

 

Thank you to everyone that has been helping thus far! I really appreciate all the support on this.

 

 

Thank you for your help! Are there any other options that we can explore for me to gather data for you? I'm fairly comfortable with technology and wouldn't mind diving into this problem using whatever debugging tools you could equip me with. I'm hesitant to pass along the movie in question as it's copyrighted material.

 

Also, I seem to have stumbled on to another odd piece to the puzzle and perhaps it's my own misunderstanding of what is going on when a movie is required to be transcoded. If I connect my Roku2 via a wired Ethernet connection, the movie transcodes correctly, and streams almost instantly. If I move back to a wireless connection the Roku gives up before starting to play the content. I've verified a number of items related to connectivity and have reviewed numerous packet captures taken at various points through the path. I cannot seem to find anything network related that would be to blame. Is there any tool on the Roku itself that might be able to help me understand what the difference would be (or that would generate enough logs for me to pass on)?

 

Thank you all very much!

de0x3

The copyrighted material would be used to research your issue, and falls into fair use (at least in USA).

 

You can use the roku network screen to diagnose it. Go to the roku homescreen and press these buttons on the remote:

Home 5x, Right dpad, Left dpad, Right dpad, Left dpad, Right dpad

 

If you do it correctly you will wind up on the network screen. From here you can change lots of things, and see visualizations in real time. Using this screen should be all you need to find a good spot to place the roku2 where it can get a good signal.

Edited January 31, 2017 by speechles

[de0x3 0]

Hi Speechles,

 

Thank you!  I examined the location the Roku is in; the Roku itself shows that it has Excellent signal.  The packet caps that I've been examining also don't show a lot of retransmits, or other network oddities.  I also played with some of the items within the Secret Wireless menu which allowed me to test other network antenna configurations -- none of which changed any of the output dramatically enough to lead me to believe that moving the Roku would help.

 

I'm curious, is there anything in the Emby for Roku app that might tell me whether there is something different going on between the wired and wireless connections?

 

(Sorry for the edit)

 

Thanks!

de0x3

Edited January 31, 2017 by de0x3

[speechles 1920]

You can use the blue neon app, enable debug in preferences, and then try to do things. After you notice it repeated the issue, go back to the homescreen, in the options row click on debug logs. These can give a clue what is happening. Look for the ::roVideoScreenEvent lines. Then somewhere it should have isRequestFailed showing up. That usually has a message line too. These messages are generated by the roku firmware so these messages are shown in log verbatim. Some of them are vague, some are descriptive. Knowing what the message is will help tell what might be causing it.

 

Sent from my Nexus 7 using Tapatalk