semmtex

Update: The newest Plex version 1.18.0.1846 finally seems to fix this issue. I still get the following error in the Plex Docker log: failed to open /data/jenkins/conan_build/290854758/conan/.conan/data/libva/2.4.0-1/plex/stable/package/9e07aef203e7a776d49230f7e190457a5658b628/lib/dri/hybrid_drv_video.so But all the streams finally start as they should and either use HW transcoding or fall back to SW transcoding for the streams my iGPU doesn't support.

Started way back with ClarkConnect, had a small interim with Windows Server, went to OMV and FreeNAS until I finally found and landed on UNRAID. Being able to use disks of different sizes was the first and foremost reason to choose and stick with UNRAID. However, going on four years now and can't imagine using anything else anymore. What started as a file server has grown into a fully fledged server with enterprise-class features that I enjoy daily. Thanks Lime Tech! On to many more years!

I know that this has to do with Plex. And multiple users have already reported this at the Plex Forums. I was just stating that this error occurs in the Plex log, but that it doesn't seem to impair the HW transcoding ability. Yes. On 6.7.X I have a lot more CPU usage when transcoding than on 6.6.7 utilising QuickSync HW Transcoding. EDIT: If there's another way to double check that i915 is really utilised while transcoding, I'm all ears...

I am having the exact same issue. I posted about it here: and here: We don't seem to be the only ones experiencing this problem. As Switch points out, the problem does not occur on UnRaid 6.6.7. So I'm thinking it's most likely a kernel issue. Even when downgrading I still experience the "Failed to wrapper hybrid_drv_video.so" error in the Plex Docker log. However the hardware transcoding DOES seem to be functioning. The "kernel: i915 0000:00:02.0: Resetting vecs0 for hang on vecs0" error which potentially locks up the entire UnRaid system -- if I don't stop the docker fast enough -- does not occur on UnRaid 6.6.7. Specs: M/B: Supermicro - X10SLH-F/X10SLM+-F CPU: Intel® Xeon® CPU E3-1285L v4 @ 3.40GHz

No problem, but I was kinda hoping for a more elaborate fix. For I'm having the same issues with with the iGPU passthrough using Binhex PlexPass container on unraid 6.7.0 . It used to work perfectly, but even with an updated container the problem still arises.

@emmcee How did you resolve this error?

Having problems with Hardware transcoding on Unraid 6.7.0 and running Binhex Docker Build 1.15.6.1079 It used to work perfectly, however whenever I activate Hardware Transcoding now and transcode a stream I get the following errors: In the Plex Docker Log: failed to open /data/jenkins/conan_build/290002784/conan/.conan/data/libva/2.1.0-40/plex/stable/package/81a2df5e16044d97d1b088b0e6c9598b5b17f233/lib/dri/hybrid_drv_video.so Failed to wrapper hybrid_drv_video.so In the Unraid Log: kernel: [drm] GPU HANG: ecode 8:6:0xacdfbffd, in Plex Transcoder [26671], reason: hang on vecs0, action: reset kernel: i915 0000:00:02.0: Resetting vecs0 for hang on vecs0 The stream itself will say that it's using HW transcoding, but it never starts, just keeps on buffering according to Tautulli and sometimes crashes the docker and even unraid itself. Help is greatly appreciated!

Anyone find a good solution to this problem? Downgrading Plex doesn't seem to fix the problem for me. So I'm thinking maybe the problem stems from somewhere else? Now on Unraid 6.7.0 and running Binhex Docker Build 1.15.6.1079 Whenever I activate Hardware Transcoding and transcode a stream I get the following errors: In the Plex Docker Log: failed to open /data/jenkins/conan_build/290002784/conan/.conan/data/libva/2.1.0-40/plex/stable/package/81a2df5e16044d97d1b088b0e6c9598b5b17f233/lib/dri/hybrid_drv_video.so Failed to wrapper hybrid_drv_video.so In the Unraid Log: kernel: [drm] GPU HANG: ecode 8:6:0xacdfbffd, in Plex Transcoder [26671], reason: hang on vecs0, action: reset kernel: i915 0000:00:02.0: Resetting vecs0 for hang on vecs0 If I don't act fast during this error it has even resulted in a full system crash, needing to reboot. UPDATE OCTOBER 2019: The newest Plex Media Server v1.18.0.1846 finally seems to fix this problem for me. I do still get the "failed to open..." message in the Plex Docker log, but everything seems to work as it should. No more hang on vecs0!

Give-away fun!! As on this forum also semmtex on Twitter.

I've been having trouble with my server for a while now. When I don't run any dockers the server runs just fine. However when I want to resume normal operation with several dockers (couchpotato, transmission, sickrage and plex) running, I can be certain it'll crash when several dockers are running their chores (eg. Downloading, unpacking, streaming). This is the crash report I see most often (pic). I can't add my diagnostics report since it's a hard crash, in need of a hard reboot. I already ran safe-mode, memtest, and xfs_repair. With the last one making some repairs after a blackout, but everything else comes out just fine. So any help would be appreciated. In the meantime I'm thinking that I'm asking too much of my server and that it's in need of an upgrade. What are your thoughts? Specs: Mobo: Asus M4A8-VM CPU: AMD Athlon XII 245 Memory: 4gb

Was just reading another post about kernel panics in which you suggested the same. It's def on my agenda for this weekend! Thanks. I'll report back later...

Still having trouble, this time it crashed just by adding a torrent into transmission webui. It started okay, but after about 5 min. This happens...(see picture) Help much appreciated!

I'm not using Xen, and running the latest unraid version with a couple of dockers (Transmission, Plex, Sickrage, CP). I'll take a look at the thread, maybe there's something in there.

Did that a week ago, let it run for more than 25 hours. Didn't find anything. I reckon it's probably old or faulty hardware, but no clue what it might be myself.

Spoke too soon. Here's another crash. Had to connect monitor, since it totally unresponsive.

Been running okay so far. Really think it could be a plugin or installed package?

Don't use an Microsoft account to login to windows, instead use a local one. That solved the problem for me at least!

My solution was changing account back to a local one on Win10 instead of the Microsoft account. Finally restored my access to Unraid SMB!

Booted into SAFE mode, attached the diagnostics zip-file. phoenix-diagnostics-20150719-1417.zip

Sorry 'bout that...thanks for the move.

First I had a corrupt btrfs docker image. I recreated this and re-added my docker containers. So far so good. However every time my server crashes. The problem lies with the Plex docker. Whenever the Plex docker crashes I can still access the Unraid Webui, however stopping the plex docker results in an unresponsive Webui, and a according to the docker ps command still running Plex docker. Normally I proceed by killing the docker daemon (rc.docker) which reinstates the Webui, although not this time. Only solution became a hard reset. Any help or indication on how to prevent/fix the problem is much appreciated. Excerpt from syslog below, full syslog attached: Jul 17 18:59:01 Phoenix kernel: general protection fault: 0000 [#1] PREEMPT SMP Jul 17 18:59:01 Phoenix kernel: Modules linked in: veth xt_nat md_mod iptable_filter kvm ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat ip_tables tun k10temp pata_atiixp i2c_piix4 r8169 ahci mii libahci asus_atk0110 acpi_cpufreq [last unloaded: md_mod] Jul 17 18:59:01 Phoenix kernel: CPU: 0 PID: 5943 Comm: Plex Media Serv Tainted: G W 4.0.4-unRAID #5 Jul 17 18:59:01 Phoenix kernel: Hardware name: System manufacturer System Product Name/M4A78-VM, BIOS 1601 10/15/2009 Jul 17 18:59:01 Phoenix kernel: task: ffff88004860b1e0 ti: ffff88011a934000 task.ti: ffff88011a934000 Jul 17 18:59:01 Phoenix kernel: RIP: 0010:[<ffffffff810ab21e>] [<ffffffff810ab21e>] find_get_entry+0x41/0x7d Jul 17 18:59:01 Phoenix kernel: RSP: 0018:ffff88011a937cd8 EFLAGS: 00010246 Jul 17 18:59:01 Phoenix kernel: RAX: ffff880019f97b10 RBX: ff00000000000000 RCX: 00000000fffffffa Jul 17 18:59:01 Phoenix kernel: RDX: ffff880019f97b10 RSI: ffff880019f97b10 RDI: 0000000000000000 Jul 17 18:59:01 Phoenix kernel: RBP: ffff88011a937cf8 R08: ffff880019f97908 R09: ffff88011a937cc0 Jul 17 18:59:01 Phoenix kernel: R10: 0000000000000040 R11: 0000000000000293 R12: 000000000003507c Jul 17 18:59:01 Phoenix kernel: R13: ffff880083b88158 R14: ffff880083b88150 R15: 000000000003507c Jul 17 18:59:01 Phoenix kernel: FS: 00002b335cc01700(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000 Jul 17 18:59:01 Phoenix kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Jul 17 18:59:01 Phoenix kernel: CR2: 00002b3362c38000 CR3: 00000001042ee000 CR4: 00000000000007f0 Jul 17 18:59:01 Phoenix kernel: Stack: Jul 17 18:59:01 Phoenix kernel: 0000000000000000 000000000003507c 0000000000000000 0000000000000000 Jul 17 18:59:01 Phoenix kernel: ffff88011a937d48 ffffffff810ab9f1 ffff88010cd0a000 0000000000001000 Jul 17 18:59:01 Phoenix kernel: 00002b3360962493 000000000003507c ffff88000add7200 0000000000001397 Jul 17 18:59:01 Phoenix kernel: Call Trace: Jul 17 18:59:01 Phoenix kernel: [<ffffffff810ab9f1>] pagecache_get_page+0x28/0x153 Jul 17 18:59:01 Phoenix kernel: [<ffffffff810ac3b0>] generic_file_read_iter+0x176/0x555 Jul 17 18:59:01 Phoenix kernel: [<ffffffff812379f7>] fuse_file_read_iter+0x58/0x5d Jul 17 18:59:01 Phoenix kernel: [<ffffffff810f76ef>] new_sync_read+0x78/0x9c Jul 17 18:59:01 Phoenix kernel: [<ffffffff810f8094>] __vfs_read+0x14/0x3b Jul 17 18:59:01 Phoenix kernel: [<ffffffff810f813f>] vfs_read+0x84/0x11e Jul 17 18:59:01 Phoenix kernel: [<ffffffff810f821b>] SyS_read+0x42/0x86 Jul 17 18:59:01 Phoenix kernel: [<ffffffff81604e09>] system_call_fastpath+0x12/0x17 Jul 17 18:59:01 Phoenix kernel: Code: 29 e2 fc ff 4c 89 e6 4c 89 ef e8 af 12 2c 00 48 85 c0 48 89 c6 74 2d 48 8b 18 48 85 db 74 38 f6 c3 03 74 07 f6 c3 01 74 2e eb d9 <8b> 53 1c 85 d2 74 d2 8d 7a 01 89 d0 f0 0f b1 7b 1c 39 d0 74 08 Jul 17 18:59:01 Phoenix kernel: RIP [<ffffffff810ab21e>] find_get_entry+0x41/0x7d Jul 17 18:59:01 Phoenix kernel: RSP <ffff88011a937cd8> Jul 17 18:59:01 Phoenix kernel: ---[ end trace 8e0c4bfaef2b5b09 ]--- syslog-plex-crash.zip

I've got a similar problem. Did you find a fix yet? Running RC4 now, but will reboot and update to 6.0.0 hoping that'll fix it. I think the problem has something to do with the plex docker at least. Since my other dockers still run and work. Just an unresponsive WebUi and Plex.

Just use his workaround! It's written down a couple of pages back, just copy and paste that code in your go file and alter it to accommodate your plugins. A lot easier than it might sound... And then everything works like a charm again! Thanks PhAzE!

First of all...Thank you very much PhAzE for making these Plugins public and for making them at all. So far I'm using Transmission, CouchPotato, Plex and they work as advertised. I also just installed SickBeard, but I'll be waiting on your update so that I can install the SickRage version, or perhaps others if anyone has a better alternative to the discontinued TPB one? Anyway, mostly just saying thanks...