Buffering when playing 1080p on AppleTV with QNAP TS-653D

Server Version#: 1.21.1.3766 and 3795
Player Version#: 7.11 (22422)

I have just upgraded from a QNAP TS-653B (Celeron J3455) to a TS-653D (Celeron J4125). Several 1080P movies which were playing find on my AppleTV with my old NAS won’t play with the new one at all. They are constantly buffering with the error message “The server is not powerful enough…” or so. The CPU and IO at that time is very low (<5%) and PMS is showing that hw-Transcoding is taking place. If I enable hw-Transcoding, the movies are playing ok.

PMS Build 3795 does not help even though is mentions support for newer Intel CPUs in the readme.

Is there anything more I can do?

I recently upgraded to the TS-453D 8GB from the TS-253be 8GB. I have an Apple TV4K and noticed an issue until I disabled ‘Automatically Adjust Quality’ in settings inside the Plex App on my ATV. I don’t know if that will help you, but it did me. ALSO PMS just came out with another update for QNAP. :slight_smile:

Hey Josh,
yes but no :slight_smile:
I already played around with the player settings and also installed the new version. No change.
But actually I found the culprit, the mkv-container with the movie with the buffering issue contained a subtitle track. After I deactivated the subtitle track the video played ok without any transcoding.
Still, the D model performed worse than the BE/Be models all parameters being equal.

Aparently, Intel has already fixed this problem on their side. Hopefully a Plex Media Server release will soon integrate it (if it hasn’t already?)

cc @ChuckPa

DEBUG (not VERBOSE) LOGFILES PLEASE which capture this?

As preface: J4xxx CPUs are still NAS-grade processors.

Consider:

2200 vs 2700 Passmarks.

If any subtitle burning involved – game over.

This is why log files are needed to diagnose and resolve questions.

That the CPUs in question are not high end is understood but the slower CPU is able to transcode while the faster and newer is not. The driver bug linked pombeirp looks promising.

Regarding the logs - do you need the PMS server logs or the Player logs or both?

Server logs only (DEBUG mode only) please.

Player logs are of no use because I only need see the result of their dialog. (MDE: information block)

Here is the server log file of one of the problematic videos.
(File removed)

@Variag

Thank you.

The log is clear. Subtitles are being burned.

Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] Scaled up video bitrate to 5662Kbps based on 1.500000x fudge factor.
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Selected protocol hls; container: mkv
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: analyzing media item 716674
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): no direct play video profile exists for http/mkv/h264
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): no direct play video profile exists for http/mkv/h264/dca
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): selected sidecar subtitle stream cannot be direct played
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): selected sidecar subtitle stream cannot be direct played
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): selected subtitle cannot be converted to a compatible format, burning into video stream
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): avoiding video remux due to burned subtitle stream
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Captive State (2019): no remuxable profile found, so video stream will be transcoded
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] MDE: Cannot direct stream video stream due to profile or setting limitations
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] Codecs: testing h264 (decoder) with hwdevice vaapi
Dec 20, 2020 20:30:11.341 [0x7f06e509e700] DEBUG - [Transcode] Codecs: hardware transcoding: testing API vaapi
Dec 20, 2020 20:30:11.342 [0x7f06e509e700] DEBUG - [Transcode] [FFMPEG] - Format 0x41524742 → bgra.

Per the spec (I’ve not added to the NAS guide due to testing incomplete).

J4xxx CPU family. It will buffer burning subtitles.

  1. HW decode
  2. HW encode
  3. CPU software subtitle burning.

This is how it’s done because Intel never provided a HW-subtitle layer.

Use Text-Based and let the player perform overlay if you must use subtitles.

Image based subtitles (PGS, VOBSUB, and DVDRIP) are always burned regardless.

Hello Chuck, yes, I switched off the subtitles and all was well.

Still the Gemini Lake hw transcoding performed worse than the one for the Apollo Lake CPU. Futher investigation leads to multiple mentions for Intel, Synology and QNAP platforms similarly effected, for instanc When will HW transcoding be fixed?

The workaround you mentioned in this Post (QNAP HW transcoding stuttering) works in so far as the movie plays correctly including transcoding:

  1. PMS 1.19.5 for QNAP now provides direct access to Preferences.xml in the “PlexData” share in File Station.
    -or-
  2. Install / use PMSLibShare
  3. Using a Linux (not Windows) text editor (QNAP text editor is recommended), Add VaapiDriver="i965" before the closing /> at the end of Preferences.xml . Put a space before and after this setting.

Please understand me.

  1. These CPUs do not have the power to burn subtitles in most cases.
  2. That as basis, turning off subtitles proves the point. NAS boxes (unless a big Intel or AMD) don’t have the CPU power.
  3. Reference to the VaapiDriver for HW transcoding has no impact on subtitles.
  4. Subtitles are always burned in Software – Not VAAPI

If there is an issue with NON-subtitle files, I will gladly help look into it further.

At present, my time is fully monopolized on Synology DSM 7 packaging.
I will glady come back to here in a few days ( :crossed_fingers: ) when it is working in the preview.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.