My downloads have been jpg for each page instead of a single nzb. Has that been the same for everyone else or did I screw up a setting and Mylar did the processing to cbr prior?
https://pastebin.com/bZTJSwK2
Thanks
jpg instead of CBR
-
- Posts: 11
- Joined: Thu Jul 26, 2018 10:37 pm
Re: jpg instead of CBR
Mylar v 0.5.2 master
OS - Unraid container - Mylar3 linuxserver's
Problem - File downloads using NZBGet and shows up in the appropriate folder as set by the category in NZBGet and shows as success from post processing. The problem is then it stays as a number of jpg files (essentially the cbr broken out).
I can add a new series to the folder main dir '/comics' so Mylar should have all the necessary permissions to move and edit files.
Thank you again
OS - Unraid container - Mylar3 linuxserver's
Problem - File downloads using NZBGet and shows up in the appropriate folder as set by the category in NZBGet and shows as success from post processing. The problem is then it stays as a number of jpg files (essentially the cbr broken out).
I can add a new series to the folder main dir '/comics' so Mylar should have all the necessary permissions to move and edit files.
Thank you again
-
- Posts: 11
- Joined: Thu Jul 26, 2018 10:37 pm
-
- Posts: 11
- Joined: Thu Jul 26, 2018 10:37 pm
Re: jpg instead of CBR
Seems pretty evident this is a NZBGet vs Sab issue. I have setup the two downloaders identical. Both have the same paths and all that good stuff setup so both point to the same locations for source and downloads. But I can get the downloads to work w/ Sab and not Get. Oh well. More troubleshooting later.
It's my neighbor's fault talking me into shifting to Get.
It's my neighbor's fault talking me into shifting to Get.
- evilhero
- Site Admin
- Posts: 2883
- Joined: Sat Apr 20, 2013 3:43 pm
- Contact:
Re: jpg instead of CBR
It sounds like you have nzbget unpacking the rar files, which results in just a bunch of image files. Older versions of nzbget would automatically unpack cbr files as they were detected as rar files (which they are) - which created problems. That was years ago however, and hasn't been an issue for a very long time since it won't unpack cbr and cbz now by default unless overridden.
Odds are there's a setting in nzbget that is telling it to unpack cbr fikes instead of keeping them (or a script if you have any scripts running after a download).
i haven't looked at the carepackage so this could all be wrong, but based on your description alone, and the fact that it works as intended with sab, it would seem to point to a possible incorrect configuration of some kind with nzbget.
Odds are there's a setting in nzbget that is telling it to unpack cbr fikes instead of keeping them (or a script if you have any scripts running after a download).
i haven't looked at the carepackage so this could all be wrong, but based on your description alone, and the fact that it works as intended with sab, it would seem to point to a possible incorrect configuration of some kind with nzbget.
-
- Posts: 11
- Joined: Thu Jul 26, 2018 10:37 pm
Re: jpg instead of CBR
Thank you for the intel. No scripts running. Will try and do further troubleshooting tonight looking expressly at the unpack.
Thank you again.
Thank you again.
-
- Posts: 11
- Joined: Thu Jul 26, 2018 10:37 pm
Re: jpg instead of CBR
So setting unpack to "no" keeps the cbr from being broken into jpg. I now get the following:
2021-05-17 17:01:05 WARNING Unable to complete post-processing call due to not finding file in the location provided. [{'status': True, 'NZBID': 14, 'comicid': '133180', 'issueid': '829668', 'apicall': True}]
2021-05-17 17:01:05 WARNING no file found where it should be @ /data/intermediate/Serial.002.2021.Digital.Mephisto-Empire.#14 - is there another script that moves things after completion ?
2021-05-17 17:01:05 DEBUG found matching completed item in history. Job has a status of DELETED/COPY
2021-05-17 17:01:05 WARNING Unable to locate NZBID 14 in active queue. Could it be finished already ?
2021-05-17 17:01:05 DEBUG valid queue result returned. Analyzing...
2021-05-17 17:01:05 DEBUG Now checking the active queue of nzbget for the download
2021-05-17 17:01:05 INFO Now loading from queue: {'status': True, 'NZBID': 14, 'comicid': '133180', 'issueid': '829668', 'apicall': True}
so nzbget has an intermediate folder in the downloads but changing the category download to that location on get doesn't help. Will keep at it. Don't know why it would think that is the location. It is not a valid data path for anything. Oh well. Thanks again
2021-05-17 17:01:05 WARNING Unable to complete post-processing call due to not finding file in the location provided. [{'status': True, 'NZBID': 14, 'comicid': '133180', 'issueid': '829668', 'apicall': True}]
2021-05-17 17:01:05 WARNING no file found where it should be @ /data/intermediate/Serial.002.2021.Digital.Mephisto-Empire.#14 - is there another script that moves things after completion ?
2021-05-17 17:01:05 DEBUG found matching completed item in history. Job has a status of DELETED/COPY
2021-05-17 17:01:05 WARNING Unable to locate NZBID 14 in active queue. Could it be finished already ?
2021-05-17 17:01:05 DEBUG valid queue result returned. Analyzing...
2021-05-17 17:01:05 DEBUG Now checking the active queue of nzbget for the download
2021-05-17 17:01:05 INFO Now loading from queue: {'status': True, 'NZBID': 14, 'comicid': '133180', 'issueid': '829668', 'apicall': True}
so nzbget has an intermediate folder in the downloads but changing the category download to that location on get doesn't help. Will keep at it. Don't know why it would think that is the location. It is not a valid data path for anything. Oh well. Thanks again
- evilhero
- Site Admin
- Posts: 2883
- Joined: Sat Apr 20, 2013 3:43 pm
- Contact:
Re: jpg instead of CBR
NZBGet has this weird status that's 'DELETED/COPY' which means that the original download was deleted or copied to another location and the reference in the history is pointing to the deleted copy.
NZBGet won't re-download an item that's in that state as it's apparently being stored in a different path to what's being returned (or something along those lines).
The only fix I was able to come up with (this was months and months ago I noticed this problem), was to make sure that the item is removed from your history before using Mylar to download. Once it's removed, Mylar will be able to locate it properly in the NZBGet history as at that point it's considered a new download - but that status (which is only in NZBGet) is just a bugger to deal with and from what I recall, I haven't been able to come up with a new way of getting the altered path location properly.
NZBGet won't re-download an item that's in that state as it's apparently being stored in a different path to what's being returned (or something along those lines).
The only fix I was able to come up with (this was months and months ago I noticed this problem), was to make sure that the item is removed from your history before using Mylar to download. Once it's removed, Mylar will be able to locate it properly in the NZBGet history as at that point it's considered a new download - but that status (which is only in NZBGet) is just a bugger to deal with and from what I recall, I haven't been able to come up with a new way of getting the altered path location properly.
-
- Posts: 11
- Joined: Thu Jul 26, 2018 10:37 pm
Re: jpg instead of CBR
Thanks for that. I went with setting up a SabNZB to just handle Mylar. Seems to be running peachy now. Sorry for the trouble and thank you again for the assist.