Jump to content


Popular Content

Showing content with the highest reputation since 06/23/19 in Reports

  1. 3 points
    This is continuation of this original issue report. There is some conflicting information in that topic and, therefore, with your help, we want to try and get to the bottom of this. We have several test servers running trying to reproduce this problem, so far hasn't happened. The first thing we want to definitively establish is whether the problem is isolated to only those cases where /config inside the container is mapped to: /mnt/user/appdata vs. /mnt/cache/appdata or /mnt/diskN/appdata Note: it does not matter what the "Default appdata storage location" is set to on Settings/Docker page. Of interest is the actual path used by an individual container. What I'd like to ask is this: For those of you who have seen this DB corruption occur after updating from Unraid 6.6.x to 6.7.x, please note the placement of your 'appdata' folder and how it's mapped to your problematic container. Then update to 6.7.2 and run normally until you see corruption. At that point, please capture diagnostics and report how appdata is being mapped. If this is a huge PITA for you, then bow out of this testing - we are not trying to cause big disruptions for you. Finally I want to make clear: we are not "blaming" this issue on any other component, h/w or s/w, and also not "admitting" this is our problem. We have not changed any code we're responsible for that would account for this, which doesn't mean we don't have a bug somewhere - probably we do, and a change in the kernel or some other component might simply be exposing some long hidden issue. We are only interested in identifying and fixing the problem.
  2. 2 points
    Hi, I've posted this already, but into an incorrect forum where it remained unnoticed. So sorry for the x-post. Symptoms: Plex HW transcoding does not work with Docker on unRAID 6.7.x (0 through 2), although it is working fine when downgrading to 6.6.7 without any change in unRAID or Docker container configuration. go file: #!/bin/bash #Setup drivers for hardware transcoding in Plex modprobe i915 chmod -R 777 /dev/dri #Start the Management Utility /usr/local/sbin/emhttp & syslinux.cfg untouched as i915 support is included OOB for some time now, however during my troubleshooting attempts, I've tried to force i915 support by modifying the aforementioned config file like this (with no effect of course): label Unraid OS menu default kernel /bzimage append pci=realloc=off initrd=/bzroot i915.alpha_support=1 /dev/dri is being passed to the Plex docker container as a device and is visible to the container: root@532cd6092721:/# ls -la /dev/dri total 0 drwxr-xr-x 2 root root 80 Jun 19 11:05 . drwxr-xr-x 6 root root 360 Jun 19 11:05 .. crw-rw---- 1 root video 226, 0 Jun 19 11:05 card0 crwxrwxrwx 1 99 users 226, 128 Jun 19 11:05 renderD128 Plex transcoder does appear to see the iGPU device, Plex dashboard shows that a HW transcode session is ongoing, however video keeps buffering and playback is never initiated. I've checked Plex log quite extensively and they do IMO confirm what I've stated above - the transcoder sees the iGPU, transcode session starts, but there is no video being output. Jun 19, 2019 15:38:32.248 [0x15102bbfd700] DEBUG - TPU: hardware transcoding: using hardware decode accelerator vaapi Jun 19, 2019 15:38:32.248 [0x15102bbfd700] DEBUG - [Universal] Using local file path instead of URL: /movies/Captain Marvel (2019)/Captain Marvel (2019) - Bluray-1080p.mkv Jun 19, 2019 15:38:32.249 [0x15102bbfd700] DEBUG - HTTP requesting GET Jun 19, 2019 15:38:32.249 [0x151093dfe700] DEBUG - Auth: authenticated user 1 as obfuscated Jun 19, 2019 15:38:32.249 [0x15102b1f8700] DEBUG - Request: [ (Loopback)] GET /library/streams/181 (14 live) GZIP Signed-in Token (obfuscated) Jun 19, 2019 15:38:32.252 [0x15102b1f8700] DEBUG - Content-Length of /movies/Captain Marvel (2019)/Captain Marvel (2019) - Bluray-1080p.en.srt is 91753. Jun 19, 2019 15:38:32.253 [0x151093dfe700] DEBUG - Completed: [] 200 GET /library/streams/181 (14 live) GZIP 3ms 91753 bytes Jun 19, 2019 15:38:32.253 [0x15102bbfd700] DEBUG - HTTP 200 response from GET Jun 19, 2019 15:38:32.253 [0x15102bbfd700] DEBUG - Detected character set of UTF-8. Jun 19, 2019 15:38:32.254 [0x15102bbfd700] DEBUG - Downloaded stream from [] (codec: srt) to temporary file [/transcode/Transcode/Sessions/plex-transcode-jk19rtdgc5dtot7fu88d8gsy-ef1b128f-4370-4808-a01d-07825b462435/temp-0.srt] Jun 19, 2019 15:38:32.254 [0x15102bbfd700] DEBUG - TPU: hardware transcoding: zero-copy support present Jun 19, 2019 15:38:32.254 [0x15102bbfd700] DEBUG - TPU: hardware transcoding: using zero-copy transcoding Jun 19, 2019 15:38:32.254 [0x15102bbfd700] DEBUG - TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi Jun 19, 2019 15:38:32.255 [0x15102bbfd700] DEBUG - Job running: EAE_ROOT='/tmp/pms-85736070-8352-49fb-956e-d7be9ba4a099/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/config/Library/Application\ Support/Plex\ Media\ Server/Codecs/21b5515-2321-linux-x86_64/' XDG_CACHE_HOME='/config/Library/Application Support/Plex Media Server/Cache' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:0' 'h264' '-hwaccel:0' 'vaapi' '-hwaccel_fallback_threshold:0' '10' '-hwaccel_output_format:0' 'vaapi' '-codec:1' 'dca' '-analyzeduration' '20000000' '-probesize' '20000000' '-i' '/movies/Captain Marvel (2019)/Captain Marvel (2019) - Bluray-1080p.mkv' '-analyzeduration' '20000000' '-probesize' '20000000' '-i' '/transcode/Transcode/Sessions/plex-transcode-jk19rtdgc5dtot7fu88d8gsy-ef1b128f-4370-4808-a01d-07825b462435/temp-0.srt' '-filter_complex' '[0:0]hwupload[0];[0]scale_vaapi=w=1278:h=538:format=nv12[1];[1]hwupload[2]' '-filter_complex' '[0:1] aresample=async=1:ocl='\''stereo'\'':osr=48000[3]' '-map' '[2]' '-metadata:s:0' 'language=eng' '-codec:0' 'h264_vaapi' '-b:0' '2717k' '-maxrate:0' '3623k' '-bufsize:0' '7246k' '-r:0' '23.975999999999999' '-force_key_frames:0' 'expr:gte(t,0+n_forced*5)' '-map' '[3]' '-metadata:s:1' 'language=eng' '-codec:1' 'aac' '-b:1' '148k' '-f' 'dash' '-min_seg_duration' '5000000' '-skip_to_segment' '1' '-time_delta' '0.0625' '-manifest_name' '' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'dash' '-map' '1:s:0' '-metadata:s:0' 'language=eng' '-codec:0' 'ass' '-f' 'segment' '-segment_format' 'ass' '-segment_time' '1' '-segment_header_filename' 'sub-header' '-segment_start_number' '0' '-segment_list' '' '-segment_list_type' 'csv' '-segment_list_size' '2147483647' '-segment_list_separate_stream_times' '1' '-segment_format_options' 'ignore_readorder=1' 'sub-chunk-%05d' '-start_at_zero' '-copyts' '-vsync' 'cfr' '-y' '-vaapi_device' '/dev/dri/renderD128' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' '' Jun 19, 2019 15:38:32.256 [0x15102bbfd700] DEBUG - Jobs: Starting child process with pid 586 Jun 19, 2019 15:38:32.281 [0x15102adf6700] DEBUG - Request: [ (Loopback)] PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress?status=startup (15 live) Signed-in Token (obfuscated) Jun 19, 2019 15:38:32.282 [0x151093dfe700] DEBUG - Completed: [] 204 PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress?status=startup (15 live) 0ms 203 bytes (pipelined: 1) (range: bytes=0-) Jun 19, 2019 15:38:32.282 [0x1510916b8700] DEBUG - Request: [ (Loopback)] PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress?status=opening (15 live) Signed-in Token (obfuscated) Jun 19, 2019 15:38:32.282 [0x151093dfe700] DEBUG - Completed: [] 204 PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress?status=opening (15 live) 0ms 203 bytes (pipelined: 2) (range: bytes=0-) Jun 19, 2019 15:38:32.284 [0x15102aff7700] DEBUG - Request: [ (Loopback)] PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress?status=opened (15 live) Signed-in Token (obfuscated) Jun 19, 2019 15:38:32.284 [0x151093fff700] DEBUG - Completed: [] 204 PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress?status=opened (15 live) 0ms 203 bytes (pipelined: 3) (range: bytes=0-) Jun 19, 2019 15:38:32.284 [0x15102b9fc700] DEBUG - Request: [ (Loopback)] PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress/stream?index=0&id=0&codec=h264&type=video (14 live) Signed-in Token (obfuscated) Jun 19, 2019 15:38:32.285 [0x151093fff700] DEBUG - Completed: [] 206 PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress/stream?index=0&id=0&codec=h264&type=video (14 live) 0ms 256 bytes (pipelined: 4) (range: bytes=0-) Jun 19, 2019 15:38:32.285 [0x15102adf6700] DEBUG - Request: [ (Loopback)] PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress/stream?index=1&id=0&codec=dts&type=audio (14 live) Signed-in Token (obfuscated) Jun 19, 2019 15:38:32.285 [0x151093fff700] DEBUG - Completed: [] 206 PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress/stream?index=1&id=0&codec=dts&type=audio (14 live) 0ms 256 bytes (pipelined: 5) (range: bytes=0-) Jun 19, 2019 15:38:32.340 [0x1510916b8700] DEBUG - Request: [ (Loopback)] PUT /video/:/transcode/session/jk19rtdgc5dtot7fu88d8gsy/ef1b128f-4370-4808-a01d-07825b462435/progress/streamDetail?index=0&id=0&codec=h264&type=video&profile=High&language=eng&width=1920&height=808&interlaced=0&level=41&frameRate=23.9 Affected systems: As evidenced by other users, it appears only 7th gen Intel processors including UHD600 iGPU are affected, namely Celeron J4105 (Gemini Lake) Thanks in advance for looking into this.
  3. 1 point
    re: Trying to get to the bottom of this... First we have not been able to reproduce, which is odd because it implies there may be some kind of hardware/driver dependency with this issue. Nevertheless I want to start a series of tests, which I know will be painful for some since every time DB corruption occurs, you have to go through lengthy rebuild process. That said, we would really appreciate anyone's input during this time. The idea is that we are only going to change one thing at a time. We can either start with 6.6.7 and start updating stuff until it breaks, or we can start with 6.7.2 and revert stuff until it's fixed. Since my best guess at this point is that the issue is either with Linux kernel, docker, or something we have misconfigured (not one of a hundred other packages we updated), we are going to start with 6.7.2 code base and see if we can make it work. But actually, the first stab at this is not reverting anything, but rather first updating the Linux kernel to the latest 4.19 patch release which is 4.19.60 (6.7.2 uses kernel 4.19.55). In skimming the kernel change logs, nothing jumps out as a possible fix, however I want to first try the easiest and least impactful change: update to latest 4.19 kernel. If this does not solve the problem (which I expect it won't), then we have two choices: 1) update to latest Linux stable kernel (5.2.2) - we are using 5.2 kernel in Unraid 6.8-beta and so far no one has reported any sqlite DB corruption, though the sample set is pretty small. The downside with this is, not all out-of-tree drivers yet build with 5.2 kernel and so some functionality would be lost. 2) downgrade docker from 18.09.06 (version in 6.7.2) to 18.06.03-ce (version in 6.6.7). [BTW the latest Docker release 19.03.00 was just published today - people gripe about our release numbers, try making sense of Docker release numbers haha] If neither of those steps succeed then ... well let's hope one of them does succeed. To get started, first make a backup of your flash via Main/Flash/Flash Backup, and then switch to the 'next' branch via Tools/Upgrade OS page. There you should see version 6.7.3-rc1 As soon as a couple people report corruption I'll publish an -rc2, probably with reverted Docker.
  4. 1 point
    Have a thread going with 13 reports of AMD motherboards that, after upgrade to the latest BIOS, get the following error for Windows 10 VMs with GPU pass-through: vfio: Unable to power on device, stuck in D3 It affects the x300, X400, and the new X570 series mobos. This has been an issue since March 2019 when AMD motherboard manufacturers began preparing for the AMD 3000 CPUs. In the thread, I noted during some early research that the same issue plagued the AMD TheadRipper on x399 motherboards back in 2018(??), and I think the final solution came in the form of a Linux Kernel upgrade. This is my first report. Let me know if I need to change anything, or if it's not applicable here. Thank you!
  5. 1 point
    I've seen several people reporting slower network speeds (tests and real work performance) are slower after upgrading to 6.7.0 I've seen this with the Speedtest plugin and a Win 10 VM going to speedtest.net. Speed is about 200Mbps slower than in version 6.5.4 (in my case). Others have seen the same issue of speed difference between 6.6.7 (normal expected speeds) and 6.7.0 (slower speeds by 200-300Mbps).
  6. 1 point
    Please see this thread for more information. I've seen the same behavior since 6.6 and now on to 6.7. Also with 2 completely different servers (completely different hardware).