semmtex

Members
  • Posts

    26
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

semmtex's Achievements

Noob

Noob (1/14)

2

Reputation

  1. 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.
  2. 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!
  3. 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...
  4. 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
  5. 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.
  6. @emmcee How did you resolve this error?
  7. 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!
  8. 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!
  9. 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
  10. 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...
  11. 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!
  12. 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.
  13. 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.
  14. Spoke too soon. Here's another crash. Had to connect monitor, since it totally unresponsive.