Closed thompatry closed 2 years ago
I'm trying to understand what's happening here. But this /media/storage/downloads/TVShows_Org/
is your postprocessing folder?
/media/storage/downloads/TVShows_Org is where my downloads go to and then /media/storage/media/TV Shows is where the processed media is organized at.
On Thu, Jun 2, 2022, 1:47 PM p0ps @.***> wrote:
I'm trying to understand what's happening here. But this /media/storage/downloads/TVShows_Org/ is your postprocessing folder?
— Reply to this email directly, view it on GitHub https://github.com/pymedusa/Medusa/issues/10710#issuecomment-1145198253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK3H4EHTCBX7UKX4Q7OQ33VND6UJANCNFSM5XV2FCOQ . You are receiving this because you authored the thread.Message ID: @.***>
So you have those episodes in tvshows_org. Why don't you clean that up? Or where they supposed to be postprocessed?
There is a symlink from tvshows_org to TV Shows. The renamed file is in the TV Shows folder so I can continue to seed. Would it help of I show my post processing config in a screenshot?
On Thu, Jun 2, 2022, 2:09 PM p0ps @.***> wrote:
So you have those episodes in tvshows_org. Why don't you clean that up? Or where they supposed to be postprocessed?
— Reply to this email directly, view it on GitHub https://github.com/pymedusa/Medusa/issues/10710#issuecomment-1145217502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK3H4GUX67RIWMFB4CIJ6TVNEBFPANCNFSM5XV2FCOQ . You are receiving this because you authored the thread.Message ID: @.***>
Okay so for those episodes you already postprocessed them once. Then after that you deleted the files. So thats why they now have the status archived. And because your reprocessing a folder with media files (which are seeding) it tried postprocessing them again.
Do I sum it up correct?
Yes they have been post processed once. The file still exists, it just symlinked. For example /media/storage/downloads/TVShows_Org/Modern.Family.S06.720p.AMZN.WEBRip.DD+5.1.x264-KORPOS/Modern.Family.S06E09.Strangers.in.the.Night.720p.AMZN.WEBRip.DD+5.1.x264-KORPOS.mkv -> '/media/storage/media/TV Shows/Modern Family/Season 06/Modern.Family - S06E09 - Strangers in the Night.mkv'
It only happens with the files that are marked Archived which I never marked archived. Does that help?
How does Medusa decide to change the episode to Archived? I never deleted the files itself. Because I am looking as some of the shows I have and there are random seasons that are marked Archived. There also random episodes that Archived in the middle of the season.
I am going to just manually go through everything and marked everything back to downloaded. That looks like it resolves my issues. I am not sure why random episodes and seasons are marked archived.
Reopening. It has to deal with this pull that was added in.
Medusa only archives when 1. you delete / move the file from /media/storage/media/TV Shows/
folder.
or 2. When you manually change the file to Archived through the UI.
We've seen in the past that it also can happen when for example a mount becomes temporary unavailable. Medusa then also doesn't see the files anymore, so it assumes you moved them.
As for that PR. That was a change to prevent you from postprocessing files, where the destination has been archived. As we had users that downloaded, watched the media, removed//moved it. And then somehow something postprocessed again for that ep. So it's just a failsafe.
But if that proves to be problematic, then I revert that change.
Also I suspect you are using the Schedule postprocessing
. That will reprocess you entire seeded folder every x minutes. That's pretty inefficient.
We also provide the Automatic download handler/handling
. That will communicate with the download client for when to process a file. It also has an option to remove media after a certain seed ratio has been reached. I would strongly advice to use that if possible.
Can you provide a debug log of a postprocess run, now that you have changed the status for those eps?
From your first comment, I can see where it could be from when the NFS mount was unavailable from a network blip. With regards to reverting it, I don't think we need to do that quite yet. I understand what you are trying to do. I am just not sure what the solution is quite yet. I haven't studied the code enough yet.
From your second comment, you are correct, I have it scheduled to run every 10 minutes. It is a killer on speed since it is always processing. After we are done debugging, I will switch it to Automatic download handler/handling
. This is a nice feature to have and didn't realize it was added in. Thanks for that!
Last but not least, here are the debug logs.
Yeah so its breaking off the postprocessing for each episode because source and destination have the same file size. In stead of it breaking off cause destination has status archived.
I have changed all the episodes back to downloaded and it says that.
Just wanted to say that I had a similar experience when network drives are not available https://github.com/pymedusa/Medusa/issues/10158
What is strange is that it doesn't give the error message.
Processing aborted for /media/storage/downloads/TVShows_Org/The.Office.US.S07.720p.BluRay.x264-CLUE/the.office.us.s07e02.720p.bluray.x264-clue.mkv:
I was digging trying to figure this out and I am having no luck. I put the following line right above the raise EpisodePostProcessingAbortException
in and it doesn't ever show up in the logs.
self.log(u'Manually Search:"{0}", Status:"{1}"'.format(self.manually_searched,ep_obj.status), logger.DEBUG)
Thoughts?
Describe the bug I noticed when the post-processing is running, it is try to "post-process" it but it already set to archive. This must have been introduced into v1.0.0
To Reproduce The the episode to archived and let the automatic post process run.
Expected behavior It should not try to process Archived episodes and should not generate a warning.
Medusa (please complete the following information):
Debug logs (at least 50 lines): General > Advanced Settings > Enable debug
Additional context I did not have this issue a week ago.
EDIT: 06/02/22 Cleaned up the log