"Playback Error"s in several browsers

[yuzu_pup 0]

Heya,

 

I'm having issues playing back certain media files from the web app specifically. Accessing these files via Emby for Android or Emby Theater works fine.

 

Server isn't displaying any issues in the logs from what I can tell. Encoding seems fine:

embyserver.txt

ffmpeg-transcode-b39a0d34-52a0-46d4-b777-797bd8e6c0f2_1.txt

 

Testing from Chrome and Brave gives me generic media decode errors in the logs. I started logging from the point I clicked the play button on the media that's failing:

brave-browser.log

chrome-browser.log

 

Firefox isn't really much better:

firefox-logs.txt

 

Any idea where else to start?

 

I am able to play back some files. I seem to have the most luck with lower res files (< 480p). Bitrate is not limited on the server

Edited December 28, 2019 by yuzu_pup

[Happy2Play 8278]

To me it looks like a driver/HWA issue.  I would ask if the same happened with HWA disabled?

01:56:06.368 Stream mapping:
01:56:06.368   Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_vaapi))
01:56:06.368   Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame))
01:56:06.368 Press [q] to stop, [?] for help
01:56:06.386 [h264_vaapi @ 0x1f11700] Driver does not support some wanted packed headers (wanted 0xd, found 0).
01:56:06.386 [h264_vaapi @ 0x1f11700] Driver does not support packed sequence headers, but a global header is requested.
01:56:06.386 [h264_vaapi @ 0x1f11700] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).

[yuzu_pup 0]

Ah, yep. Works without hardware acceleration. Lemme see if I can update my drivers.

 

 

 

To me it looks like a driver/HWA issue.  I would ask if the same happened with HWA disabled?

01:56:06.368 Stream mapping:
01:56:06.368   Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_vaapi))
01:56:06.368   Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame))
01:56:06.368 Press [q] to stop, [?] for help
01:56:06.386 [h264_vaapi @ 0x1f11700] Driver does not support some wanted packed headers (wanted 0xd, found 0).
01:56:06.386 [h264_vaapi @ 0x1f11700] Driver does not support packed sequence headers, but a global header is requested.
01:56:06.386 [h264_vaapi @ 0x1f11700] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).

Edited December 28, 2019 by yuzu_pup

[yuzu_pup 0]

@Happy2Play:

 

So I was able to update my drivers and it worked! Turned hardware accelerated transcoding back on and everything seemed fine. Interestingly, I'm still getting that error message you pointed out in the logs:

 

ffmpeg-transcode-ca77db48-e437-45ef-a486-eb9355a3fbbf_1.txt

 

Am I missing something? It is still using hardware encoding, correct?

[softworkz 3335]

@Happy2Play:

 

So I was able to update my drivers and it worked! Turned hardware accelerated transcoding back on and everything seemed fine. Interestingly, I'm still getting that error message you pointed out in the logs:

 

ffmpeg-transcode-ca77db48-e437-45ef-a486-eb9355a3fbbf_1.txt

 

Am I missing something? It is still using hardware encoding, correct?

 

Yes, this is still using hw encoding. 

It doesn't use hw decoding because the AMD hardware does not support the HEVC Main10 for decoding.

But encoding is the most important part anyway.

[Luke 37050]

Please note that updating drivers is part of our hwa setup guide that the server dashboard links to.

[yuzu_pup 0]

Please note that updating drivers is part of our hwa setup guide that the server dashboard links to.

It's frustrating to be told to read the docs when nothing with the behavior, in the error messages, and in the logs lead me to believe this was the issue. I've had HWA enabled since I installed Emby. My media was transcoding fine for Android and Emby Theater. If HWA is to blame, the error message the web app provides when it fails to load a stream should direct me to this guide you're talking about.

[softworkz 3335]

I agree with you that it should be like you're describing.

 

The problem on our side is, that there's no 1-to-1 mapping between errors and possible causes for errors. Ffmpeg errors often not really precise.

For example, sometimes it reports "hardware device not available" even when just some parameters have been set incorrectly - so we cannot rely on that.

 

Another idea would be to check driver versions - but Nvidia is the only manufacturer that has a consistent versioning, whereas that's totally chaotic in case of Intel. Their versioning is way too complicated to keep up with it. And I haven't even talked about non-Windows platforms.

 

That's why I currently don't see much room for improvement in that area - unfortunately.

[yuzu_pup 0]

That's fair, and I had a feeling the lack of reliable mapping was the reason why you weren't providing more specific, actionable errors. I think it's worth at least adding a bullet to your "How to Report Errors" guide to update server drivers. I know that's probably an obvious first step, but to me as an end user, it wasn't.

 

Thanks for taking a look into this and for helping me fix it!

[Luke 37050]

It's frustrating to be told to read the docs when nothing with the behavior, in the error messages, and in the logs lead me to believe this was the issue. 

 

I understand. The whole reason we write the docs though is to avoid this initial round of troubleshooting so that we can focus on things that are actually issues.