Jump to content

Emby Server on Nvidia Shield Pro: Unsafe at any bitrate


Netfool
 Share

Go to solution Solved by ebr,

Recommended Posts

I'm running Emby Server on a 2019 Nvidia Shield Pro.  I'm trying to watch on an LG TV connected to the HDMI output of the Shield.

When I try to play a video with a 5MB/sec bitrate the video stalls about 30 minutes in.  Looking at the dashboard over the web UI it shows that the video it transcoding because .mkv is an "incompatible container".   Transcoding the video with ffmpeg (on the linux media file store machine) using ffmpeg -i <filename> -codec copy  <filename.mp4> and then rescanning the entire movies library I attempted to play the .mp4 version.   That also stalled within a minute or two of "resuming".  Again looking at the dashboard over the web UI it shows that video is also attempting to transcode on the fly.

Looking at the Emby Client "Playback Settings" on the shield and turning the "Streaming Bandwidth" down to 3MB/sec has no effect on the problem.

What is the maximum bandwidth Emby Server on an NVIDIA Shield can play through the HDMI output, and is it necessary to re-encode all of the videos in the library (roughly 6TB) at or below that bitrate in order to use Emby Server on the Shield?

embyserver.txt ffmpeg-remux-34cf853d-de26-4967-a2ce-c6b9a472e1ac_1.txt ffmpeg-remux-499b73b7-2fb4-4312-9b1d-d49659f7a37b_1.txt ffmpeg-transcode-559c15c4-ca1b-42a9-9ca8-614ae67ff117_1.txt ffmpeg-transcode-7449dc73-6162-462b-b328-33c38057b455_1.txt ffmpeg-transcode-301022b8-d0aa-418e-b692-efdee44bfd2c_1.txt ffmpeg-transcode-953166a6-817e-4a50-af9f-16eade38bdd7_1.txt ffmpeg-transcode-a0ede76b-340a-4577-8c83-69211d5e9117_1.txt ffmpeg-transcode-db07d03a-66fb-4570-80ff-ce6c24a7145f_1.txt ffmpeg-transcode-fe1f8007-a874-4246-acba-0e53874e4df7_1.txt

Link to comment
Share on other sites

cayars

It's not a bitrate problem but something else to do with the media itself most likely.

Can you post detailed information about the media you are trying to play?

What do you see at the bottom of the detail page for the movie under MEDIA INFO?

Link to comment
Share on other sites

Attached is the screenshot of the Media Info for the .mp4 version of the file.  I've deleted the .mkv version of the file because the Shield asserts that ".mkv is not a supported container".

As to whether it's stopping because the Shield is running out of space, how do I tell?   I've not been able to find anything in the Shield UI nor in any of the Emby settings that tells me how much free space there is.  I don't know that much about the android o/s.  Is there a way to ssh in and do a "df -h" to find out?  All of the media is on the Gigabit LAN and I added a Sandisk 128GB USB 3.1 drive to augment the Shield's 16 GB of internal storage.  As far as I know there is no way to add RAM to the shield.

542250061_ScreenShot2020-07-19at11_47_48AM.thumb.png.37e25acc656af112f6fcf6430103b455.png

Link to comment
Share on other sites

cayars

I don't see any issues looking at the metadata.

What is "orville" or asked another way, where does this file reside on your network?

Link to comment
Share on other sites

Orville is a headless Linux box with 6 (soon to be 12)TB of hard disk running Ubuntu 18.04 LTS and SAMBA server. It's connected via gigabit ethernet.  Both Orville and the Shield are in my TV cabinet connected to a Netgear Gigabit switch with 18-in ethernet cables.

One additional bit of information I forgot to include in this morning's post is that if I watch with the TV connected to an Emby Client on an AppleTV, (plugged into the same switch) rather than watching the HDMI output on the shield everything that failed in the earlier case plays fine.  So maybe the shield just can't be both a server and a client simultaneously?   (A shame really because the Shield's remote is vastly superior to the Apple TV's). 

Edited by Netfool
Link to comment
Share on other sites

cayars

Can you try something for me?

Turn off debug logging if on.

Use the schedule task to recycle the log file.

While trying to minimize stuff going to the log file play back a single movie/show and when you have the issue NOTE the time and upload the Server and ffmpeg logs.  Having a time stamp or rough time will make this slightly easier.

Thanks

Link to comment
Share on other sites

The puzzle is getting more complex.  So far, this one is "direct playing".   ....but it's an mkv, and there's no mention of an "unsupported container" in the web UI dashboard.  If it completes I'll rotate the log again, try another, and report back when I can reproduce the problem.

Screen Shot 2020-07-19 at 2.54.01 PM.png

Edited by Netfool
Link to comment
Share on other sites

Have you tried using an external player, like Kodi?  The internal player sometimes can't tell what exactly the hardware is capable of playing, where as Kodi knows the whole ins and outs of your device.

Link to comment
Share on other sites

I have captured and example.  I rotated the log at 8:14:47 PM (embyserver-63730786487.txt) and started to play the video through the Shield's HDMI out. 

At about 8:30 PM the video stalled.  I rotated the log again (embyserver.txt) and resumed playing it through the Emby client on the AppleTV. It played flawlessly until the end. (It was paused manually for a few minutes but resumed normally).

Attached are screenshots of the Media Info page and the server logs listing to help sort out the order of the ffmpeg logs as the log file names are utterly useless for that purpose without a secret decode ring.

RanmaCanada: I've not tried routing through Kodi.  The goal here is to make the Shield's rather nice remote usable.  It's much better than Apple TV's and I'm really not interested in adding yet another remote to my already too-large collection.  

Files with Media Info specifying plain H264 Tag: avc1 and H264 AVC: yes appear to have this problem, and files simply labeled H264 appear not to.  ....but the sample size is still low so I could be going down the wrong rabbit hole with that assumption.  Ffmpeg has a codec flag called codec_tag that takes an integer value, but I don't know how that maps to the three cases above. 

Right now all the evidence points to it being a really bad idea to have both Emby Server and Emby client on the Shield Pro.  <sigh>

Screen Shot 2020-07-19 at 11.14.34 PM.png

Screen Shot 2020-07-19 at 11.05.50 PM.png

Screen Shot 2020-07-19 at 11.06.04 PM.png

embyserver-63730786487.txt embyserver-63730787510.txt ffmpeg-directstream-27db22b8-8cc4-47a5-b0d6-29b3db488d36_1.txt ffmpeg-transcode-3b90b0d1-e7b7-4c76-b8b9-5a9442ec8bac_1.txt ffmpeg-transcode-9067d07f-4083-4843-9184-be53739b41d4_1.txt ffmpeg-transcode-e720bd0f-a4ff-42db-bd6b-a2f634338349_1.txt hardware_detection-63730787521.txt ffmpeg-transcode-9067d07f-4083-4843-9184-be53739b41d4_1.txt hardware_detection-63730787521.txt ffmpeg-transcode-3b90b0d1-e7b7-4c76-b8b9-5a9442ec8bac_1.txt ffmpeg-directstream-27db22b8-8cc4-47a5-b0d6-29b3db488d36_1.txt embyserver-63730787510.txt embyserver.txt

Link to comment
Share on other sites

ebr

Based on your description of the problem, I still suspect the Shield running out of space or some other resource during transcoding, but haven't found the evidence to prove that yet...

Link to comment
Share on other sites

So clearly we need a way to find out.   How do I get Emby and Emby Server on the Shield to tell me what it's using in the way of space and other resources?   ....and what do the different H264 flavors have to do with it.

I'm going to try "Converting" some of the H264 Tag: avc1 and H264 AVC: yes files and see if they end up as "plain" H264 files.    Any suggestions as to which conversion settings to try first?

Link to comment
Share on other sites

cayars

Probably going to be trial and error. You may want to try using Xmedia Recode if on Windows as it's GUI Based and pretty easy to use.

Link to comment
Share on other sites

No, I'm on Mac and Linux.   I was hoping to use Emby Servers conversions, but It didn't take long to find that path quesionable.   I tried converting the video in that last Media Info shot above.  The one that played smoothly on the Apple TV but not on the Shield.

I did a conversion using the "TV" defaults and "Original Quality".   It took less than a second to fail.  Logs attached.

This seems to confirm the conclusion I came to in the "Transport Stream Conversions Fail" thread earlier in this forum:  Emby Server on the Nvidia Shield Pro can't reliably do conversions.    I'll try just using ffmpeg on linux.   It's a royal pain to use, but once I get an incantation that works, i can at least call it in a bash script.

Zandr, one of the users in this forum,  once said "Ffmpeg is like a Swiss Army Knife with 100 blades.  It can do anything but there's no usable handle."

embyserver-63730836877.txt ffmpeg-transcode-34e46d7c-ed8d-4d42-ad62-fef0e11dfda1_1.txt

Link to comment
Share on other sites

cayars

Your transcode shows an error:

10:13:23.083 Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input

That would explain a lot of your issues if these files are malformed.

@softworkz can you take a look?

Link to comment
Share on other sites

softworkz

I can't see anything special except the negative timing value.

We should do the typical troubleshooting: try multiple files (different ones, of course not multiple episodes from the same series package), disable hw enoding, decoding, both, etc..

Link to comment
Share on other sites

softworkz

Remember: A single failing file is rarely an evidence for anything. 🙂

PS: The resolution is unusual, you could try with a normal one (but just a small chance that it is this)

Link to comment
Share on other sites

1 hour ago, softworkz said:

Remember: A single failing file is rarely an evidence for anything. 🙂

PS: The resolution is unusual, you could try with a normal one (but just a small chance that it is this)

Well... I agree, but this is becoming circular.   My experience is that files identified in the Media Browser as CODEC: H264  AVC: Yes and CODEC: H264  TAG: avc1 cannot be played to completion through the HDMI port, but play completely when streamed to an AppleTV on the same LAN connected to the same TV.  Files identified as simply CODEC: H264 play either way just fine.

When I state the problem that way I'm asked for Media Info screen shots and log files of a specific example.   Supplying those gets the response "A single failing file is rarely and evidence for anything".

There does not appear to be any way to use Emby Server's "Convert" process to get from H264 files that don't work to those that do.

Is there an ffmpeg incantation that can do that in Linux?

Could you perhaps please suggest a next step short of abandoning Emby Server on the Shield Pro.

Link to comment
Share on other sites

softworkz
18 minutes ago, Netfool said:

When I state the problem that way I'm asked for Media Info screen shots and log files of a specific example.   Supplying those gets the response "A single failing file is rarely and evidence for anything".

 

I apologize for the misunderstanding. My message above was addressed at  @cayars to remind him not to forget to ask about trying multiple files.

It has happened quite some times that we've gone through dozens of troubleshooting posts only to find out that it was just about a single corrupted video file and nobody had thought about asking to try other videos.

18 minutes ago, Netfool said:

Well... I agree, but this is becoming circular.   My experience is that files identified in the Media Browser as CODEC: H264  AVC: Yes and CODEC: H264  TAG: avc1 cannot be played to completion through the HDMI port, but play completely when streamed to an AppleTV on the same LAN connected to the same TV.  Files identified as simply CODEC: H264 play either way just fine.

 

H.264 is the same as AVC and AVC1 and the only reason for that digit '1' to exist is that this is the "FourCC Code" and 'AVC' is just three letters.

Emby is using  ffmpeg and ffprobe internally, and those different representations you are seeing (Codec and Tag) is coming from ffprobe. It's to some extent anachronism, but there's still a factual differrence. IIRC it's a different kind of encapsulation, could also be a different container, though.

18 minutes ago, Netfool said:

There does not appear to be any way to use Emby Server's "Convert" process to get from H264 files that don't work to those that do.

Is there an ffmpeg incantation that can do that in Linux?

Could you perhaps please suggest a next step short of abandoning Emby Server on the Shield Pro.

Just disable HW acceleration as the next step, then you will have ffmpeg software decoding and encoding.

ffmpeg "eats" just about everything. Hardware codec implementations are different and can be very picky about formats as they are typically optimized for common/mainstream content, and even small deviations from the spec can cause them to fail.

Best regards
softworkz

Link to comment
Share on other sites

cayars

He has tried several different files and that is what lead us to the difference in AVC1 vs h.264 as the subtype difference but more tests are still needed.

AVC1 and h.264 are not the same thing.  There are differences in the subtype, such as h.264 is a bitstream with start codes while AVC1 is a bitstream without start codes.

AVC1 has a long history of giving decoders and splitters a hard time and causing failures over the early years.  The HW on the shield may be having a similar issue with this subtype as well but that's only a hunch at this point as more testing is needed. Also a possibility is the source of the files and they way they were prepared.

The AVC1 files pose no problem with nvidia or intel GPUs when HW transcoding that I know of at least not on my PC system.

I agree with turning off HW in the Transcode setting on Emby server on the Shield TV and trying these same problem files again to see the outcome.  If my hunch is correct they will play and convert with HW turn off.

Link to comment
Share on other sites

softworkz
6 minutes ago, cayars said:

AVC1 and h.264 are not the same thing.  There are differences in the subtype, such as h.264 is a bitstream with start codes while AVC1 is a bitstream without start codes.

That's not correct. Yes, there are different bitstream/encapsulation types and it is true that the one variant can often be found in files having AVC1 as FourCC tag, but essentially, AVC1 is nothing other than a FourCC tag with the '1' filling the missing letter.

AVC1 is not part of any spec or standard.

 

 

Link to comment
Share on other sites

cayars

https://docs.microsoft.com/en-us/windows/win32/directshow/h-264-video-types?redirectedfrom=MSDN

H.264 Video Types

Edited by cayars
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
 Share

×
×
  • Create New...