• Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Transient

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It does seem to be due to the browser cache as Squid said. Here's what I did in Chrome: Open the noVNC window, see the error Press ctrl+shift+i to bring up Dev Tools Go to the Network tab Check "Disable cache" Press ctrl+r to reload noVNC will load successfully from now on, close Dev Tools I'm not sure what the steps are in other browsers. It would be nice for an update to resolve this in a user-friendly way. eg. attaching a version or something to the script name so the correct copy is loaded.
  2. I have 64GB of ECC RAM, so it shouldn't be that, but I'll give that a try anyway. Who knows, the part that creates the temp file might be failing which is why it ends up set to None. I had a quick look through your log and it looks like you have something else going on. It doesn't seem to have any errors or even pick up any files to transcode at all.
  3. You might be having the same problem as me. I traced it down to the cache path (where it does its transcoding) sometimes evaluating as None, but I couldn't see how the situation arises. I sent some details over to Josh.5 but I don't think he's had a chance to review it yet. I would suggest you also share your unmanic.log with him. If someone else is reporting the same issue, I imagine it would help identify what's going wrong.
  4. Just letters, numbers, spaces and round brackets ( ). Nothing unusual.
  5. I can, although I'm not really comfortable sharing it here. That said, checking unmanic.log, I found my workers all report this: 2020-10-22T11:28:30:ERROR:Unmanic.Worker-0 - [FORMATTED] - Exception in processing job with Worker-0: - expected str, bytes or os.PathLike object, not NoneType Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/unmanic/libs/", line 224, in run self.process_task_queue_item() File "/usr/local/lib/python3.6/dist-packages/unmanic/libs/", line 203, in process_task_queue_item self.current_
  6. Those ones are very old. It's probably best to wait and see what josh5 has to say.
  7. As the previous user said, just add :119 to the end of the repository name. This means to pull the one tagged 119. When left off, it will pull the one tagged latest. To find the tags, you can check Docker Hub. The easiest way IMO is to turn on Advanced View in Unraid (top right) then scroll down to your Unmanic container and click the little link that says By: josh5/unmanic. That'll take you over to Docker Hub and you can go to the Tags tab and see all the previous versions. ...only I just tried it and it looks like josh5 has since removed all tags other than latest so
  8. It did indeed fix the error, however it appears to have been unrelated. Now I have no errors in the log, but it still doesn't process anything. All the workers are idle even though there are several pending. If I roll back to 119 everything works again. Is there any information I can provide that would be useful in identifying the problem?
  9. I reverted to tag 119 (which I think was probably the previous working version?) and now I'm back in action.
  10. I am also having the same problem. It is not working at all after updating and has been running fine since February or so previous to this. I think the new update has broken something. The logs show something about the database being locked over and over. I tried running a "PRAGMA integrity_check" against the db, which came back "ok". I also tried doing a dump and importing back into a new DB. Neither resolved the issue. [E 201021 11:40:53 web:1788] Uncaught exception GET /dashboard/?ajax=pendingTasks&format=html ( HTTPServerRequest(protocol=
  11. I think this is a bug in Unmanic. On the audio encoding settings page it states: "Modify the audio stream codec. Channel count and bitrate are kept the same as the source." So it shouldn't be reducing the number of channels while re-encoding.
  12. Yes and I meant the only copy that exists is on disk5. 😁
  13. There is only one copy of the file on disk5. Also, if I run qemu-img check /mnt/user/VM/disk3.qcow2 it reports no issues.
  14. Hello, After upgrading from 6.8.0 to 6.8.2 I'm getting an error when starting one of my VMs: Could not read qcow2 header: Invalid argument The qcow2 image it is referring to resides on the array: /mnt/user/VM/disk3.qcow2 It starts fine if I change it to directly reference the drive it is on: /mnt/disk5/VM/disk3.qcow2 Any idea why this is suddenly a problem? Is this a known issue with 6.8.2? Thanks!