5/21/2023 0 Comments Dri crash plan![]() I just recently started using this docker for encoding movies and videos, and I ran into issue that someone may be able to help me out with. But I'm not sure if the solution applies to unRAID though. For example, I found the following post, which seem to describe your problem. I think this is not related to the container itself, but to the Linux version of HandBrake (you would probably be able to reproduce the same behaviour in a Linux VM). What's not clear is why the container is stuck on synching disks and won't allow the array to shutdown or the container to stop gracefully. My instinct tells me there is something here with permissions and possibly the fact this is USB hardware. Bottom line is that everything's golden if the disk reads perfectly, but when it doesn't, then I have to hard down the server because I can't get the container to shut down. This is happening with the latest release and with the last most recent container release. I am exposing both drive devices through extra parameters. ![]() I'm not running the container in priveleged mode. In the container log it always hangs on 'syncing disks'-even if I haven't gotten past the actual identification of the disk, when trying to stop the container it hangs there. So in other words I was trying to eliminate a specific disk or drive issue. I've pulled the drive over to the same release of MakeMKV on Windows10-it does not become unresponsive under those conditions. It can read *some* disks, but when it has a problem and just reads forever-either loading the disk or during ripping-the container hangs and can't be 's worse than that as even killing the associated processes still don't allow the array to be shutdown successfully and I have to go unclean hard down. Firstly, I have a Buffalo USB drive, I've exposed both linux devices to the container. Not having an issue with any other docker - strange situation with the MakeMKV one. Starting off-new to unRAID and to Dockers in general.
0 Comments
Leave a Reply. |