Server Version#:Synology 918+ Version 1.16.3.1402
Player Version#:Roku tv, Roku
Hello,
I am running Plex natively on a Synology 918+ with hardware encoding enabled. It works for most content, but doesn’t on Plex DVR content that I had recorded previously and moved over. I haven’t tried recording new content but will shortly. Is there some limitation to the hardware transcoding/is this Synology box enough?
It starts like this but it can’t keep up:(firefox as player this time playing content just recorded)
Jul 27, 2019 11:34:11.246 [0x7fc1c455b700] DEBUG - MDE: Tour de France - S2019 E20 - Stage 20: Albertville to Val Thorens: selected media 0 / 8737
Jul 27, 2019 11:34:11.246 [0x7fc1c455b700] DEBUG - Streaming Resource: Calculated bandwidth of 20393kbps exceeds bandwidth limit. Changing decision parameters provided by client to fit bandwidth limit of 3000kbps
Jul 27, 2019 11:34:11.246 [0x7fc1c455b700] DEBUG - Streaming Resource: Determining preferred transcode encoders through transcode only decision.
Jul 27, 2019 11:34:11.246 [0x7fc1c455b700] DEBUG - Codecs: hardware transcoding: testing API vaapi
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32315659 -> yuv420p.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30323449 -> yuv420p.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x3231564e -> nv12.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32595559 -> yuyv422.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x59565955 -> uyvy422.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x48323234 -> yuv422p.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58424752 -> rgb0.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58524742 -> bgr0.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30313050 -> p010le.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Created surface 0x4000000.
Jul 27, 2019 11:34:11.254 [0x7fc1c455b700] DEBUG - [FFMPEG] - Direct mapping possible.
Jul 27, 2019 11:34:11.255 [0x7fc1c455b700] DEBUG - Scaled up video bitrate to 19165Kbps based on 1.500000x fudge factor.
Jul 27, 2019 11:34:11.255 [0x7fc1c455b700] DEBUG - Codecs: hardware transcoding: testing API vaapi
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32315659 -> yuv420p.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30323449 -> yuv420p.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x3231564e -> nv12.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32595559 -> yuyv422.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x59565955 -> uyvy422.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x48323234 -> yuv422p.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58424752 -> rgb0.
Jul 27, 2019 11:34:11.259 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58524742 -> bgr0.
Jul 27, 2019 11:34:11.260 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30313050 -> p010le.
Jul 27, 2019 11:34:11.260 [0x7fc1c455b700] DEBUG - [FFMPEG] - Created surface 0x4000000.
Jul 27, 2019 11:34:11.260 [0x7fc1c455b700] DEBUG - [FFMPEG] - Direct mapping possible.
Jul 27, 2019 11:34:11.260 [0x7fc1c455b700] DEBUG - Scaled up video bitrate to 19165Kbps based on 1.500000x fudge factor.
Jul 27, 2019 11:34:11.261 [0x7fc1c455b700] DEBUG - Streaming Resource: Reducing playback quality for 2857kbps stream bitrate: video resolution to 720x406, audio channels to 2, quality to 84
Jul 27, 2019 11:34:11.261 [0x7fc1c455b700] DEBUG - Codecs: hardware transcoding: testing API vaapi
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32315659 -> yuv420p.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30323449 -> yuv420p.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x3231564e -> nv12.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32595559 -> yuyv422.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x59565955 -> uyvy422.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x48323234 -> yuv422p.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58424752 -> rgb0.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58524742 -> bgr0.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30313050 -> p010le.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Created surface 0x4000000.
Jul 27, 2019 11:34:11.264 [0x7fc1c455b700] DEBUG - [FFMPEG] - Direct mapping possible.
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - Scaled up video bitrate to 19165Kbps based on 1.500000x fudge factor.
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - Scaled maximum bitrate for resolution reduction to 2701Kbps.
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: Selected protocol dash; container: mp4
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: analyzing media item 8737
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: Direct Play is disabled
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: media must be transcoded in order to use the dash protocol
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: no direct play video profile exists for http/mpegts/mpeg2video
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: no direct play video profile exists for http/mpegts/mpeg2video/ac3
Jul 27, 2019 11:34:11.265 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: no direct play video profile exists for http/mpegts/mpeg2video/ac3
Jul 27, 2019 11:34:11.266 [0x7fc1c455b700] DEBUG - Stage 20: Albertville to Val Thorens - video.width limitation applies: 1920 > 720
Jul 27, 2019 11:34:11.266 [0x7fc1c455b700] DEBUG - Stage 20: Albertville to Val Thorens - audio.channels limitation applies: 6 > 2
Jul 27, 2019 11:34:11.266 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: Direct Streaming is disabled, so video stream will be transcoded
Jul 27, 2019 11:34:11.266 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: no remuxable profile found, so video stream will be transcoded
Jul 27, 2019 11:34:11.266 [0x7fc1c455b700] DEBUG - MDE: Cannot direct stream video stream due to profile or setting limitations
Jul 27, 2019 11:34:11.266 [0x7fc1c455b700] DEBUG - Codecs: hardware transcoding: testing API vaapi
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32315659 -> yuv420p.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30323449 -> yuv420p.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x3231564e -> nv12.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x32595559 -> yuyv422.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x59565955 -> uyvy422.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x48323234 -> yuv422p.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58424752 -> rgb0.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x58524742 -> bgr0.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Format 0x30313050 -> p010le.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Created surface 0x4000000.
Jul 27, 2019 11:34:11.267 [0x7fc1c455b700] DEBUG - [FFMPEG] - Direct mapping possible.
Jul 27, 2019 11:34:11.268 [0x7fc1c455b700] DEBUG - Scaled up video bitrate to 19165Kbps based on 1.500000x fudge factor.
Jul 27, 2019 11:34:11.268 [0x7fc1c455b700] DEBUG - Scaled maximum bitrate for resolution reduction to 2701Kbps.
Jul 27, 2019 11:34:11.268 [0x7fc1c455b700] DEBUG - MDE: E20 - Stage 20: Albertville to Val Thorens: Audio Direct Streaming is disabled, so video’s audio stream will be transcoded
Jul 27, 2019 11:34:11.269 [0x7fc1c455b700] DEBUG - MDE: Cannot direct stream audio stream due to profile or setting limitations
Jul 27, 2019 11:34:11.269 [0x7fc1c455b700] DEBUG - MDE: Tour de France - S2019 E20 - Stage 20: Albertville to Val Thorens: selected media 0 / 8737
Jul 27, 2019 11:34:11.270 [0x7fc1c455b700] DEBUG - Streaming Resource: Reached Decision id=7833 codes=(General=1001,Direct play not available; Conversion OK. Direct Play=3000,App cannot direct play this item. Direct play is disabled. Transcode=1001,Direct play not available; Conversion OK.) media=(id=8737 part=(id=8737 decision=transcode container=mp4 protocol=dash streams=(Video=(id=5983 decision=transcode bitrate=2613 encoder=h264_vaapi width=720 height=406) Audio=(id=5985 decision=transcode bitrate=232 encoder=aac channels=2 rate=48000))))
Jul 27, 2019 11:34:11.270 [0x7fc1c455b700] DEBUG - Transcode Session: Going to restart at offset 84.017349 with segment number 27
Jul 27, 2019 11:34:11.270 [0x7fc1c455b700] DEBUG - Killing job.
Jul 27, 2019 11:34:11.270 [0x7fc1c455b700] DEBUG - Signalling job ID 8581 with 9
Jul 27, 2019 11:34:11.271 [0x7fc1c455b700] DEBUG - Job was already killed, not killing again.
Jul 27, 2019 11:34:11.271 [0x7fc1c455b700] DEBUG - Stopping transcode session 94qmjsmawjsremf7w6dvvkwb
Jul 27, 2019 11:34:11.271 [0x7fc1c455b700] DEBUG - Starting a transcode session 94qmjsmawjsremf7w6dvvkwb at offset 84.0 (state=3)
Jul 27, 2019 11:34:11.272 [0x7fc1c455b700] DEBUG - TPU: hardware transcoding: using hardware decode accelerator vaapi
Jul 27, 2019 11:34:11.273 [0x7fc1c455b700] DEBUG - [Universal] Using local file path instead of URL: /volume1/Plex/shows/Tour de France (2019)/Season 2019/Tour de France (2019) - 2019-07-27 07 00 00 - Stage 20.ts
Jul 27, 2019 11:34:11.273 [0x7fc1c455b700] DEBUG - TPU: hardware transcoding: zero-copy support present
Jul 27, 2019 11:34:11.273 [0x7fc1c455b700] DEBUG - TPU: hardware transcoding: not using zero-copy because video is interlaced
Jul 27, 2019 11:34:11.274 [0x7fc1c455b700] DEBUG - TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi
Jul 27, 2019 11:34:11.275 [0x7fc1c455b700] DEBUG - Job running: EAE_ROOT=’/volume1/Plex/tmp_transcoding/pms-e4395390-2184-45b1-a5f7-9aa97f538756/EasyAudioEncoder’ FFMPEG_EXTERNAL_LIBS=’/volume1/Plex/Library/Application\ Support/Plex\ Media\ Server/Codecs/2144ff1-2376-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’ ‘-codec:#0x100’ ‘mpeg2video’ ‘-hwaccel:#0x100’ ‘vaapi’ ‘-hwaccel_fallback_threshold:#0x100’ ‘10’ ‘-codec:#0x101’ ‘ac3’ ‘-ss’ ‘83.967998999999992’ ‘-analyzeduration’ ‘20000000’ ‘-probesize’ ‘20000000’ ‘-i’ ‘/volume1/Plex/shows/Tour de France (2019)/Season 2019/Tour de France (2019) - 2019-07-27 07 00 00 - Stage 20.ts’ ‘-filter_complex’ ‘[0:#0x100]yadif[0];[0]scale=w=720:h=406[1];[1]format=pix_fmts=nv12[2];[2]select=gte(t,83.983983)[3];[3]hwupload[4]’ ‘-filter_complex’ ‘[0:#0x101] aresample=async=1:ocl=’’‘stereo’’’:osr=48000[5]’ ‘-map’ ‘[4]’ ‘-codec:0’ ‘h264_vaapi’ ‘-b:0’ ‘1959k’ ‘-maxrate:0’ ‘2613k’ ‘-bufsize:0’ ‘5226k’ ‘-r:0’ ‘29.969999999999999’ ‘-force_key_frames:0’ ‘expr:gte(t,84+n_forced*3)’ ‘-map’ ‘[5]’ ‘-metadata:s:1’ ‘language=eng’ ‘-codec:1’ ‘aac’ ‘-b:1’ ‘232k’ ‘-bsf:1’ ‘framedrop=count=2’ ‘-f’ ‘dash’ ‘-min_seg_duration’ ‘3000000’ ‘-skip_to_segment’ ‘28’ ‘-time_delta’ ‘0.0625’ ‘-manifest_name’ ‘http://127.0.0.1:32400/video/:/transcode/session/94qmjsmawjsremf7w6dvvkwb/5710eeab-f048-4468-bc32-16a4e4599ed8/manifest’ ‘-avoid_negative_ts’ ‘disabled’ ‘-map_metadata’ ‘-1’ ‘-map_chapters’ ‘-1’ ‘dash’ ‘-start_at_zero’ ‘-copyts’ ‘-y’ ‘-vaapi_device’ ‘/dev/dri/renderD128’ ‘-nostats’ ‘-loglevel’ ‘quiet’ ‘-loglevel_plex’ ‘error’ ‘-progressurl’ ‘http://127.0.0.1:32400/video/:/transcode/session/94qmjsmawjsremf7w6dvvkwb/5710eeab-f048-4468-bc32-16a4e4599ed8/progress’
Turns out it can do it without hardware encoding enabled, but obviously this isn’t ideal.
A few questions:
I ask because, in the log file you provided, you are getting HW assist for both decode and encode which is even more indicative of subtitle involvement or a very complex audio codec.
Jul 27, 2019 11:34:11.274 [0x7fc1c455b700] DEBUG - TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi
In the future, it’s much cleaner to provide the ZIP file. We can look at other elements which are not always obvious to the customer.
After I took those logs I turned off hardware transcoding and it worked without glitching but it isn’t a good long term solution.
Turning off hw transcoding, resulting in improvement, tells me there is a major problem elsewhere.
Please uninstall PMS itself and reinstall the package. I ask this because when the installer runs, it sets DSM permissions for the hardware.’
I would then like to see the XML of the item being played and the logs (with hardware on) after doing the following:
How do I get the xml? It works without hardware transcoding but pretty much pegs the processor. Live TV from the Homerun is the same result.
Hover over the item, Expose the ellipsis. Get Info… “View XML”
Copy the media portion (top part). The actor / genre / other info below is not needed
<MediaContainer size="1" allowSync="1" identifier="com.plexapp.plugins.library" librarySectionID="2" librarySectionTitle="TV Shows" librarySectionUUID="fe43bf76-ca5d-4089-8b0f-252180b4196c" mediaTagPrefix="/system/bundle/media/flags/" mediaTagVersion="1563208077"><Video ratingKey="7833" key="/library/metadata/7833" skipParent="1" grandparentRatingKey="7831" guid="com.plexapp.agents.thetvdb://350506/2019/20?lang=en" parentGuid="com.plexapp.agents.thetvdb://350506/2019?lang=en" grandparentGuid="com.plexapp.agents.thetvdb://350506?lang=en" librarySectionTitle="TV Shows" librarySectionID="2" librarySectionKey="/library/sections/2" type="episode" title="Stage 20: Albertville to Val Thorens" grandparentKey="/library/metadata/7831" grandparentTitle="Tour de France" parentTitle="Season 2019" contentRating="TV-PG" summary="Stage 20, the penultimate day of the Tour de France, is a 130 km mountain stage from Albertville to Val Thorens." index="20" parentIndex="2019" viewOffset="219000" lastViewedAt="1564347051" year="2019" thumb="/library/metadata/7833/thumb/1564243223" art="/library/metadata/7831/art/1564243223" grandparentThumb="/library/metadata/7831/thumb/1564243223" grandparentArt="/library/metadata/7831/art/1564243223" duration="14398699" originallyAvailableAt="2019-07-27" addedAt="1564243201" updatedAt="1564243223" oneShot="1"><Media id="8737" duration="14398699" bitrate="24070" width="1920" height="1080" aspectRatio="1.78" audioChannels="6" audioCodec="ac3" videoCodec="mpeg2video" videoResolution="1080" container="mpegts" videoFrameRate="NTSC" channelIdentifier="48.1" mediaGrabBeginsAt="1564228800" mediaGrabDevice="device://tv.plex.grabbers.hdhomerun/1049257A" mediaGrabStatus="complete" origin="dvr" videoProfile="main">
<Part accessible="1" exists="1" id="8737" key="/library/parts/8737/1564243200/file.ts" duration="14398699" file="/volume1/Plex/shows/Tour de France (2019)/Season 2019/Tour de France (2019) - 2019-07-27 07 00 00 - Stage 20.ts" size="24033030008" container="mpegts" deepAnalysisVersion="4" packetLength="188" requiredBandwidths="14024,13778,13604,13411,13263,13190,12954,12954" videoProfile="main">
<Stream id="5983" streamType="1" codec="mpeg2video" index="0" bitrate="11747" bitDepth="8" chromaLocation="left" chromaSubsampling="4:2:0" closedCaptions="1" colorPrimaries="bt709" colorRange="tv" colorSpace="bt709" colorTrc="bt709" frameRate="29.970" height="1080" level="4" profile="main" refFrames="1" requiredBandwidths="13448,13202,13028,12834,12686,12614,12380,12380" scanType="interlaced" streamIdentifier="256" width="1920" displayTitle="1080i (MPEG2VIDEO)"/>
<Stream id="5985" streamType="2" selected="1" codec="ac3" index="1" channels="6" bitrate="384" language="English" languageCode="eng" audioChannelLayout="5.1(side)" requiredBandwidths="384,384,384,384,384,384,384,384" samplingRate="48000" streamIdentifier="257" displayTitle="English (AC3 5.1)"/><Stream id="5986" streamType="2" codec="ac3" index="2" channels="1" bitrate="192" language="Español" languageCode="spa" audioChannelLayout="mono" requiredBandwidths="193,193,193,193,193,193,193,193" samplingRate="48000" streamIdentifier="258" visualImpaired="1" displayTitle="Español (AC3 Mono)"/>
<Stream id="5984" streamType="3" codec="eia_608" index="0" bitrate="11747" embeddedInVideo="1" requiredBandwidths="13448,13202,13028,12834,12686,12614,12380,12380" streamIdentifier="256" displayTitle="Unknown (EIA_608)"/>
</Part>
</Media>
<Channel id="12076" filter="channel=12076" tag="48.1 WAFFDT (NBC)"/>
<Extras size="0">
</Extras></Video></MediaContainer>
TDF.txt (3.5 KB)
Moderator edit: Improve readability a bit
Thank you. Now I see it.
PMS will do the following:
What is the TV audio setting?
Auto detect… Whatever that means. It’s a Roku TV. Have options for pcm-stero, Dolby digital,Dolby digital plus, Dolby digital dts, Dolby digital plus dts
The same thing happens when Firefox is the player.
Do you have regular movies which otherwise play OK?
If so, then I know what’s happening.
The combined CPU load:
is just too much for that processor.
You can convert it to regular TV format (progressive scan instead of interlaced scan) but it will take some time. After it’s done, you will have no more issues because interlacing will have been done. You should find it as one of the recording options.
Yes everything that wasn’t recorded from Plex works perfect. I’ll give it a try and let you know.
Although the CPU usage never gets above 40% with hardware transcoding enabled.
The only recording options available through Plex is the experimental “transcode while recording option” so I gave it a try(with hardware encoding enabled…not sure if it uses it for this feature or not). It uses around 70-90% CPU while recording, but then the resultant playback with hardware transcoding still enabled does play through without stopping with CPU usage around %20. If I disable hardware transcoding, it still plays through but with a CPU usage of ~%95.
I am somewhat doubtful it is as simple as the CPU load is too much since it does play back with hardware transcoding disabled (with CPU usage around 95%). With hardware transcoding enabled the CPU usage is always around %25-%30 even when it stops to buffer and eventually stops to tell me it’s not powerful enough. It may be that it is impossible to share some loads between hardware and software in an elegant way and clearly you are better situated to understand that than me.
As it stands now it seems hardware transcoding isn’t useful for things recorded from HomerunHD (I also have 1080P content that won’t play), and liveTV from HomerunHD cannot work on this device with either hardware or software transcoding.
We will figure this out because there are many DS918+ Plex users who have zero problem with it.
If we start from the beginning; How much memory is in it? 4GB or 8GB . 8GB is recommended and easily done (up to the right of drive 4).
Fair point, I troubleshoot problems like this regularly at my day job so I may have jumped the gun a bit. I don’t really have nearly the depth of information or knowledge of the code base to say what I said. Because it works well on most media I assumed there may not be that many if any users trying to do hardware transcoding with a 918+ on content recorded from a HomerunHD.
I have 4GB of memory in my box currently. Although it doesn’t seem to be using much while transcoding(in hardware or software), it is possible that the memory hardware transcoding uses doesn’t show up in the Synology resource manager.
A breakdown of memory utilization:
When you record or watch LiveTV:
Does this show in DSM’s monitor? Yes, but only if it persists. DSM’s widget doesn’t show instantaneous spikes. Resource monitor is an averaging tool. It must see successive samples at a particular level to be reflected in the display. At that point, it averages with the previous values and induces a trend. It is only accurate when the machine has reached a steady state at whatever level it is.
Basic DVR usage is PMS + 2x Transcoder = 1 + 0.9 + 2x 350 = 2.6 GB of the 4 GB
You might be on that edge of Mpeg2 deinterlacing + audio conversion + whatever else might be running and just causing it to think it can’t do the work.
I didn’t see anything else running in PMS but re there other apps active / installed on the NAS? If so, they will also consume CPU (which is only 2700 Passmarks spread across 4 cores).
If need be, I can get you a different version of PMS to try so we can rule out this release.
How would you like to proceed?
I think I will probably buy another stick of RAM either way. In the mean time if you could help me isolate the issue by advising me on how to remove transcoder instances one at a time. Forgive my ignorance but is the i in 1080i the interlacing part? Asking so I can record some content 1080p to eliminate the deinterlacing factor. If that still fails I’d like to know a way to preconvert the audio on some test file to see if that was causing it.
The fact that it can handle all of this (for one recorded 1080i stream anyway) with the processor transcoding alone hints to me that I’m in some corner case/regression that we haven’t yet found. When hardware transcoding it’s like it does 1 segment then doesn’t start up the other one in time or something.
I would be happy to try some other version if you have a “known good” for playing HomerunHD recorded content with hardware transcoding.
Even if no transcoding is happening during a record, and no one is viewing, the transcoder is still activated and consumers 350MB RAM per recording?
No. The transcoder is silent unless otherwise needed.
One thing you should look at is the DLNA server and disable it if not needed. It leaks memory at present and Engineering is trying to resolve it. It will consume everything in a day or two.
