Server Version#: 1.19.5.3112
Player Version#:
Tuner Make/Model: HomeRun Quattro
Guide/Lineup name:
Using XMLTV?: No
Channel number/Name: Recorded TV
I just bought a Synology DS920+. One of the reasons I chose this model is that it supposedly has hardware accelerate transcoding of video content that Plex can use. Unfortunately, when I turn on hardware accelerated transcoding, the video doesn’t seem to play at all on my web browser, or it has problem repainting certain areas, or it just skips through the content playing snippets here and there. It plays fine on my Plex apps on my LG tv. However, if I turn off hardware acceleration, the video plays fine, but the CPU on my Synology spikes to 96%. Normally, the CPU on my Synology hovers around 15 - 20%. What could be going wrong? Has Plex tested with the new Synology DS920+
According to Plex’ NAS Compatibility list, this model is not yet verified to support Plex’ hw accelerated streaming (as of Aug 25, 2020: “Evaluating”)
Looking solely at the CPU it seems to have what it takes. Not sure what’s getting in the way or if there’s some technical limitation I don’t seem to see.
I can help you enable hardware acceleration in a “workaround mode” if you’re interested.
Doing this will allow Hardware transcoding but part of the problem we face on Synology (as with all acceleration) subtitle burning must be done by the CPU. Synology CPUs are typically not strong.
Before proceeding further, I would like to see the DEBUG (not VERBOSE) log files which capture the first 20 seconds of a playback session.
They will allow us to confirm why the CPU is pegging. If the issue is subtitles then you’ll need to mitigate in a different way (we can give suggestions). if the issue is purely video conversion, we can address that with ease.
Thanks for your offer to help. I’m new to Plex, so I’m not 100% sure what you mean when you say DEBUG (not VERBOSE) log files. There was no obvious way from the UI that I could see to change the debug level of the log. Also, once I downloaded the logs, it wasn’t obvious which log you wanted (there are so many). I turned on hardware encoding, and started watching a new program. The video was halting, had mis-colored sections and jumped around (as described above). I’ve attached the last transcoder statistics log file which should represent this session. I hope that is the right file.
Control of DEBUG & VERBOSE logging is located in Settings - Server - General - SHOW ADVANCED
I always request DEBUG only because folks think they’re being helpful with VERBOSE when it’s actually a hindrance.
I am not certain what’s happening with the LG and the DVR/Live-TV action.
I have not had tuner capability for almost 2 years now and a lot has changed.
It looks like the MPEG2 input isn’t being accepted properly by the TV app. (MDE should report that it can DirectPlay MPEG2)
For it to then say it can’t detect makes no sense. It’s as if the video stream isn’t right.
I used to have a HDHR3 which worked flawlessly when I had it.
Does Hardware Transcoding on the Syno itself work for movies ?
Here is what I was looking at in your logs?
Aug 26, 2020 09:29:00.482 [0x7fe1ed780700] DEBUG - Grabber: Waiting for a tuner on device://tv.plex.grabbers.hdhomerun/10798A58 (4 available) for at most 2160 seconds.
Aug 26, 2020 09:29:00.482 [0x7fe1ed780700] DEBUG - Grabber: Allocated a tuner on device://tv.plex.grabbers.hdhomerun/10798A58 (3 left)
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - We're going to try to auto-select an audio stream for account 1.
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - Selecting best audio stream for part ID -1 (autoselect: 0 language: en)
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - Audio Stream: -1, Subtitle Stream: -1
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: Selected protocol hls; container: mpegts
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] ERROR - Unable to find title for item of type 5
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: analyzing media item -1
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: : no direct play video profile exists for http/mpegts/
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: : no direct play video profile exists for http/mpegts//
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: : codec is unavailable for analysis
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: : codec is unavailable for analysis
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] ERROR - Unable to find title for item of type 5
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - MDE: : selected media 0 / -1
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - Cleaning directory for session 210f9991-7b3d-4ab1-be63-efe70a835626 ()
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - Starting a transcode session 210f9991-7b3d-4ab1-be63-efe70a835626 at offset -1.0 (state=3)
Aug 26, 2020 09:29:00.483 [0x7fe1ed780700] DEBUG - Streaming Resource: Added session 0x7fe218bfe250:210f9991-7b3d-4ab1-be63-efe70a835626
Aug 26, 2020 09:29:00.484 [0x7fe1ed780700] DEBUG - Job running: EAE_ROOT='/volume1/Plex/tmp_transcoding/pms-bddee73b-52ab-48bb-9dea-702831e1db8d/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/volume1/Plex/Library/Application\ Support/Plex\ Media\ Server/Codecs/5f603a2-3204-linux-x86_64/' XDG_CACHE_HOME='/volume1/Plex/Library/Application Support/Plex Media Server/Cache' XDG_DATA_HOME='/volume1/@appstore/Plex Media Server/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/volume1/@appstore/Plex Media Server/Plex Transcoder' '-noaccurate_seek' '-ignore_unknown' '-scan_all_pmts' '-1' '-rw_timeout' '30000000' '-reconnect' '1' '-reconnect_streamed' '1' '-reconnect_delay_max' '30' '-fflags' '+discardcorruptts+fillwallclockdts' '-probesize' '20000000' '-i' 'http://192.168.7.206:5004/auto/v44.3' '-map' '0:V?' '-codec:V' 'copy' '-map' '0:a?' '-codec:a' 'copy' '-map' '0:s?' '-codec:s' 'copy' '-break_non_keyframes' '1' '-segment_format' 'mpegts' '-f' 'ssegment' '-individual_header_trailer' '0' '-segment_time' '1' '-segment_start_number' '0' '-segment_time_delta' '0.25' '-segment_list' 'http://127.0.0.1:32400/video/:/transcode/session/210f9991-7b3d-4ab1-be63-efe70a835626/ef08ff22-18ee-40c4-a80a-4658dd5ed7ad/seglist?X-Plex-Http-Pipeline=infinite' '-segment_list_type' 'csv' '-segment_list_size' '5' '-segment_list_separate_stream_times' '1' '-segment_list_unfinished' '1' '-max_delay' '5000000' '-map_metadata' '-1' '-map_chapters' '-1' 'media-%05d.ts' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-xioerror' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/210f9991-7b3d-4ab1-be63-efe70a835626/ef08ff22-18ee-40c4-a80a-4658dd5ed7ad/progress'
Aug 26, 2020 09:29:00.484 [0x7fe1ed780700] DEBUG - Jobs: Starting child process with pid 31021
First, apologies for loading up my entire system log - I navigated to inside the zipfile and picked only the transcoder log, but apparently the entire zip file got uploaded instead.
Second, debug was already on, which you’ve probably realized from the logs. But good to know where to find it from now on.
Third, streaming to the LG app appears to work pretty well regardless of whether hardware acceleration is turned on or not. Not sure why, but maybe it doesn’t try to transcode it because the TV understands the video source natively?
Fourth, used the Synology Video Station application with hardware acceleration turned on. I mounted the plex “Recorded TV” folder inside the application and streamed the same program I was streaming this morning. It worked just fine, and the CPU stayed in the 30 - 40% range.
Finally, I ran another video in Plex with hardware acceleration turned on, and got the same result. Uploading the log here.
I actually WANT the entire ZIP file. The transcoder statistics file doesn’t tell me anything about what PMS was seeing prior to starting the transcode session which is exactly what I need to see. I need to know what it saw and why it decided to do what it did.
Hardware supported transcoding appears to be working now. The video is coming through fluid, and the CPU hovers in the 20 - 35% range. The only remaining issue appears to be that it takes between 20 - 40 seconds to start the video stream after clicking on the play button of a new video. Initially, I thought it was not working (the progress bar just kept spinning and spinning), and it was only accidentally that I discovered that it was just a long delay. Interestingly enough, moving forward in the video stream does not result in the same delay (just 2 -3 seconds, presumably for the transcoder to get ahead a little). This seems to indicate that it takes 20 - 40 seconds to spin up the video play system for a particular file. Let me know if you have any thoughts as to what might be causing this. I made the change around 9:10 this morning (but I had a false start where hardware acceleration had not been set - I fogot to hit save!!) and I have attached the logs. Thanks again for your help on this.
Your logs look MUCH better now. We can see the VAAPI (hardware) driver kicking in.
The delay you’re seeing depends on the audio at this point.
If the audio didn’t need converting, you’d have much faster startup on that CPU.
You will find that the more complex audio encodings will take longer to fill up the buffer. (All audio is done by the CPU)
As you’ve noticed, once everything is ‘spun up’, it’s a lot quicker to respond. That’s a typical behavior of that class CPU.
Happy to hear that the logs are looking much better!! As you expected, the experience inside the application is much better also. The only issue remaining is the very slow startup time for each video clip. I was not seeing the same slow startup-time when I wasn’t using hardware acceleration - the videos were starting within 3 - 4 seconds. Presumably the audio needed converting under this scenario as much as under the hardware accelerated scenario. The CPU would be pegged, but the video started in a reasonable timeframe. Any thoughts about what is causing this unreasonable start-up time? Anything we can do to improve it?
Hi ChuckPa,
Oddly enough this problem went away. Regardless of whether I’m using the web-app or using the WebOS application on my LG television, most of the streams now start in 1 - 2 seconds, and when I skip ahead (beyond the buffer), they also start in 1 - 2 seconds. CPU usage is still 14% or so. Very happy with the outcome on this. Unfortunately, I’m opening two new items about accessing live TV and some of the DVR features.
I liked reading this thread, I have a Synology DS220+… I’m just wondering is this workaround with the VAAPI driver applicable to all Synology models or atleast all DSx20 models?
I just tried this and when I went to save the file a pop up message occured stating that some text will not save due to the encoding, I erroneously clicked passed that and the content within Preferences.xml file is now quite truncated.
It is in my stupidity that I didn’t create a back up of the XML file, do you know what entry I should put into this XML file to get my Plex server finding the libraries again?
Thanks Trumpy, I managed to fix it another way but couldn’t come back to state the issue was resolved.
I only had to go in to the Authorized Devices and sort by Server, there I saw two instances for my server and deleted the one with the oldest time on it. Everything was immediately fine after that. I also found what the illegal characters were in the XML file when I was trying to save it… that was my fault too.
My server is back up and running fast, all settings remain. You can also let your colleagues know the authentication outage has been resolved on our side too, performance is back to normal.
