🐋 Some DVDs stuck in active - filling up host log #1267
Labels
Comments
|
If youre having issues, please remember to read the wiki and follow the instructions carefully |
|
If you are not using the base ARM image, Whilst 1337server is one of the Devs that container may have development code tgat is not production ready. Please refer to https://github.com/automatic-ripping-machine/automatic-ripping-machine/wiki/Alternate-Install-TrueNAS |
microtechno9000
added
the
Unsupported OS
|
Yes, sorry my mistake @microtechno9000. I changed the repository to automaticrippingmachine/automatic-ripping-machine and the same thing is happening. Originally I ruled out Unraid as the issue as the MakeMKV docker rips the dvd just fine. I did follow the guide from your link to ensure permissions where in place. |
|
Is the job stopping at MakeMKV? If so there is a known bug with MakeMKV at the moment |
|
Not OP here, but getting the exact same issue. Here's my docker command that is executed in unraid: I was able to rip one dvd, and then the very next dvd, and a bluray had the same issue as OP, with no changes from the good one. Both were able to rip from Make MKV on a windows computer using MakeMKV 1.17.8. Whole bunch of this stuff in the host log: Here are the container logs: And then after I insert the dvd: |
|
If there is an issue it will be in the job log, the docker log is just the webpage |
|
Here's the job log. I ran it again just now to capture this: At that point the host fills up with logs mentioned above forever and nothing else happens. I end up abandoning the job in ARM to stop it. |
Are you still having an issue? |
Not sure what is happening, is the issue intermittant? only DVD's? Could it be a specific DVD or drive? The below logs are normal, it is just the webpage generate status information when someone is on the main page. If you don't want to see this and fill up your docker logs, set the logging to INFO [2024-12-21 22:36:50,983] DEBUG ARM: json_api.process_logfile active
[2024-12-21 22:36:50,983] DEBUG ARM: json_api.process_logfile using handbrake
[2024-12-21 22:36:50,985] DEBUG ARM: json_api.process_handbrake_logfile Cant find index
[2024-12-21 22:36:50,986] DEBUG ARM: json_api.get_x_jobs jobs - we have 1 jobs |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this?
Does this issue exist in the latest version?
Describe the bug?
When inserting the DVD it appears in ARM as None (None) and is stuck with status Active.
Then the host (Unraid) log is being filled up with these logs
Dec 18 19:41:48 Tower kernel: UDF-fs: error (device sr0): udf_fiiter_advance_blk: extent after position 2016 not allocated in directory (ino 285) Dec 18 19:41:48 Tower kernel: UDF-fs: error (device sr0): udf_verify_fi: directory (ino 285) has entry where CRC length (36) does not match entry length (240)The arm.log contains just this
Wed Dec 18 18:41:41 UTC 2024 Entering docker wrapper Wed Dec 18 18:41:42 UTC 2024 [ARM] Starting ARM for DVD on sr0I tried ripping the same disk with makeMKV docker on Unraid with success. Which led me to open this issue.
To Reproduce
I'm not sure how this can be easily reproduced, as it seems to be only some disks (4 of 10 failed), but consistently.
Built from source files ?
What architecture are you seeing the problem on?
amd64
Expected behavior?
I expect that the ripping would start immediately like the other disks.
Relevant log output
Anything else?
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: