Anime titles with S2 (for second season) in the filename snatch properly but replace episodes in season 1 during postprocess #10481
Comments
|
Do you have the required season scene exceptions? |
|
I just postprocessed the episode And as you can see in my log.. 2022-04-08 09:56:13 DEBUG POSTPROCESSQUEUE-POST-PROCESS :: [0c9eddd] Detected a season scene exception [Tate no Yuusha no Nariagari S2 -> 2] without a season number in the title, translating the episode #1 to indexer #26: S02E01 It uses the season scene exception to match it to season 2. |
|
Please try to re-process the file again. But now enable debug logging. Make sure to restart after enabling debugs |
Not sure why snatcher recognized that filename but not postprocessor previously, but this time it figured it out. I'll monitor it when episode 2 comes out and see if it does it properly with that one (and make a backup copy of s1e2 just in case). |
|
Another series with similar issues happening, again where SubsPlease uses "S2" in the filename to denote it is season 2. Luckily my S1 is the same quality as S2 for this one, so it decided not to overwrite/replace the episode and I won't have to redownload. Here's the snatch log showing it recognizes it as s02e02 and downloading it for that purpose: And here it takes the completed file and tries to postprocess it. It identifies the file as s01e02 instead of what was identified during snatching and tries to replace my existing file in S1. Luckily the quality is the same so it just skips it. Also I'm not sure what that last error at the end is from, but it seems to happen after the file identification issue so I don't think it is related, but including it just in case and as FYI. |
|
That error we already fixed in develop branch.. |
|
For snatching I grabbed everything with "SEARCHQUEUE-BACKLOG-388317", before and after that was logs searching for other releases/shows with different "SEARCHQUEUE-BACKLOG-XXXXXX" numbers. And also for the postprocessor I grab all logs having to do with processing of that file. Before and after that were just search logging entries. But I can grab more from before (or after) if you think it is useful. I have debug logging turned off for now as I didn't want it logging crazy amounts of stuff for days. |
|
I enabled debug logging, restarted the container, and then did a manual postprocess on the directory again, and this time it worked again! (There was another unrelated file from a different series in there as well that ready for processing, so you'll probably see both in these logs.) Odd that it keeps seeming to figure it out after restarting. |
|
From the logs it seems you are using periodic postprocessing. |
|
I'm having the same issue with Kaguya-sama S3. I believe this is a new bug, since Medusa has worked for other shows with this naming convention in the past. Debug log: Here are my scene exceptions:
Is it possible that the issue is with the order of the scene exceptions? Since I am also using scheduled post-processing. |
|
My rtorrent runs in a container and is kind of finnicky, so I think that is why I used scheduled postproc as it was the most stable way to get it to work,, but I'll give download handling a try and see.
Will report back when another episode comes down. I think one should be coming up in a day or so for Shield Hero. |
|
Getting an error on download handling, not sure what is up with that? It is trying to grab that Kaguya-sama S3 episode like the other post above. It sent it to rtorrent and even paused the torrent at the end properly, as was in the settings, but doesn't like something to do with my paths. Both my "Default client path" and "Post-processing dir" are set to "/downloads/rtorrent/completed/sp" so not even sure where the above "resouce path" of "/data/completed/sp" is coming from. Needless to say, it doesn't seem to have done anything. The completed download is still in my completed folder and never got moved or processed. |
|
It gets the location directly from rtorrent. And in rtorrent (in the container) that is the Final folder for the download. The folder outside the rtorrent container is different. In theory you could create a symlink to the folder. And create the symlink as /data/completed/sp? But I do think that's kinda hacky |
Yeah I was just poking around too and realized the "/data/completed/sp" is how rtorrent sees the path. Since they are different containers (by different authors), they have different mappings to my downloads folders. I think I can add another container path to my Medusa container so it would also have a same path of "/data/completed/sp" as well. The actual location is outside the container on my unRAID server, so it wouldn't be difficult. Would that make sense and fix it? |
|
Yes that would fix it. The medusa container should have the /data/completed/sp path also. |
|
OK I added the path "/data/completed/sp" in my Medusa container, so it sees the same path as rtorrent. In my Post-processing settings I also updated "Default client path" and "Post-processing dir" to that same directory (seems logical that should be the same as well?). Will it re-process "[SubsPlease] Kaguya-sama wa Kokurasetai S3 - 01 (720p) [547050BB].mkv", or since it did already once it won't again? Shield Hero and a couple other shows I think new episodes should be coming up as well soon, so we can see if it handles them correctly (assuming I got my settings right now). |
|
I think you'll have to manually re-snatch the episode. In config / history, you can see the status of the episode. |
|
Btw I just released version 0.5.29 |
|
I manually resnatched from a different location, we'll see how it goes. The previous one's status is still just "SeededAction".
|
|
Looks like that worked this time. Now that download handler looks to be working for me, we'll see how it does on new episodes of Shield Hero and Love Live over next couple days. I see they updated the container as well, hopefully with your new release, so I'll grab that too. |
|
Oddly, it also updated the previous snatch as "Completed, Postprocessed" as well.
|
|
@lcdt22890158 looking at your logs. It looks like the It difficult for me to make conclusions from this small piece of log. Could you keep debug logs enabled, and send me all log files, next time it occurs? Like zip application.*. And send it to me through discord? You can PM me there. |
|
Medusa grabbed Shield Hero s02e02, downloaded it, and postprocessed it as s01e02 and deleted/replaced the existing file again. So it appears to do the same thing even with download handler. Here is the file processing logs. If you want more let me know. Luckily I made copies of the first few files in S1 as I thought this might happen again, so I don't need to redownload it this time at least.
|
|
So the issue here is that the release name was parsed before and cached. So the pp used the cached data. relevant logs: |
|
What is strange is that I also have a number of these animes. But I haven't had this issue a single time. But I have to agree that I also accept other release groups. I'll limit mine to subsplease for now. |
|
Clearing out some of my downloads and noticed it just happened again with a different series. This time it is "Data A Live" and it snatched s04e02 and then postprocessed it as s01e02, deleting my existing 1x02 file. SubsPlease is naming this season not with S4 but with "IV" in the title (as you can see in the logs), but still having a similar issue. Here's the snatch and processing logs. If you want all my logs to look through, if it would help, I can zip them up and send over to you somehow, just let me know where/how. |
|
Also is there a way to prevent it from deleting/replacing my existing files? I thought setting the status on them to archived would do that, but apparently not. Do I need to add the quality of the existing files to the "Preferred Qualities"? But wouldn't that mess up the new files that it is trying to download as well? Setting it to archived prevents it from trying to download replacements/upgrade for existing files when it is searching, but in this case it snatches a different file but then later decides to replace an older season's file anyway with that new one. Luckily anime has pretty good seeders and it hasn't been hard to find them again, but if this happens on some files that are extremely hard to replace or find again, that could get painful. |
|
You can pm me the logs in discord |
|
Another interesting one... This one figured it out all by itself, I didn't notice until I was looking closer at it. Initially it tried to do the replace but the existing file was same quality so it didn't overwrite it. Then it tried to download again (the file was still in my completed downloads since it had failed previously, so I assume that was pretty instant when the torrent hashes matched) and postprocessed again and this time it got the season/episode right and matched! Initial download: First attempt to postprocess, thought it was S1 and tried to replace but failed due to quality luckily: Tried to snatch again from a different tracker, but same file. This one errored out with a "big" error and also a rtorrent time out error. (I have that happen semi-frequently where it says rtorrent timed out and gives an error, but the magnet hash does actually show up in rtorrent and start working. Same, actually more commonly, with my other Medusa container where I handle live action TV shows.) Successfully grabs it this time, but rtorrent already has it from before so just 1 entry listed in my rtorrent download list: Finally, since it thinks it has a new download that completed, it attempts to postprocess again and this time it works! |
|
I'll get on the discord and send you a zip of the full logs. |
|
Think i've found the issue. Should be fixed in #10504 |
|
New S2 episode came down but it tried to replace something in S1 again, so looks like there still is something going on. |
|
Small update. I've made sure that Guessit name parsing requests from the postprocessing never atempts to get it from cache. |
|
I think the fix seems to be working, as well as can be expected. Is it still only in dev branch or has it been pushed to master? Just wondering about switching back. |
|
I think I've gotten to the bottom of it. refresh_exceptions_cache() clears the entire exception cache even when a single series is refreshed. Meaning that if we pass in a series_obj the cache will only contain exceptions for that particular show. Medusa/medusa/scene_exceptions.py Lines 35 to 45 in c5a1e37 $ grep 'New file:.* S[23] -\|Updating exc\|Processing failed for\|Finished processing' medusa-log.txt
2024-03-10 03:01:48 INFO SHOWQUEUE-SEASON-UPDATE :: [] Updating exception_cache and exception_season_cache
2024-03-10 03:01:48 INFO SHOWQUEUE-SEASON-UPDATE :: [] Finished processing 12 scene exceptions.
2024-03-10 10:35:34 INFO Thread_0 :: [] New file: /media/downloads/complete/medusa/[SubsPlease] Shin no Nakama S2 - 10 (1080p) [C46A4C07].mkv
2024-03-10 10:35:34 WARNING Thread_0 :: [] Processing failed for /media/downloads/complete/medusa/[SubsPlease] Shin no Nakama S2 - 10 (1080p) [C46A4C07].mkv: File exists. Marking it unsafe to replace. Reason: New quality is equal than
current Preferred. Ignoring quality
2024-03-10 17:15:28 INFO SEARCHQUEUE-BACKLOG-400573 :: [] Updating exception_cache and exception_season_cache
2024-03-10 17:15:28 INFO SEARCHQUEUE-BACKLOG-400573 :: [] Finished processing 4665 scene exceptions.
2024-03-10 17:15:45 INFO Thread_0 :: [] New file: /media/downloads/complete/medusa/[SubsPlease] Shin no Nakama S2 - 10 (1080p) [C46A4C07].mkvseason 2/3 episodes get incorrectly identified as season 1 after the cache is refreshed for a particular series since there are no exceptions for that show in the cache. But after refreshing the entire cache things miraculously starts working. The entire cache is refreshed right before running the download handler which explains why parsing consistently works there. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When downloading an anime series with a season 2 (or possibly later) and the scene name is "Title S2...", it snatches fine but when it goes to postprocess it, it sees it as being a season 1 file and replaces an existing file from season 1 instead of going into the season 2 (or later) folder.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I'd expect it to move the file to the Season 2 folder rather than deleting and replacing the file in Season 1 with the same episode number. Especially since the snatcher DOES recognizes it as a Season 2 file I'd expect it to pass that information to the postprocessor so that once it has completed, it can put the file in the proper location identified originally.
Screenshots
As you can see here, it snatched S02E01 but ended up moving the file to season 1 and replacing the S01E01 file.
Medusa (please complete the following information):
Debug logs (at least 50 lines):
Here's the initial snatch:
And here's the postprocessing:
Additional context
I realize the quality difference is part of the reason it did this as it thinks it should replace with the higher quality release, but the main problem is the postprocesser misidentifying the season, even though the snatcher did it correctly.
I've run into this problem previously with other series with "S2" in the name, but finally decided to create an issue for it as it isn't the first time this has happened to me.
On a non-anime related note, I've had similar things happen with live action TV shows. For example, I had the original Charmed series and the Charmed (2018) series both in my Medusa at one point at the same time. When Charmed (2018) started airing, the snatcher recgonizes and grabbed Charmed (2018) S01E01, but after it downloaded, the postprocessor thought the file was for the original Charmed series and deleted and replaced my S01E01 file there. After this happened on the first couple episodes and I realized it, I ended up having to remove the original Charmed series from Medusa so it would quit trying to delete my files. It seems like there is a disconnect between the snatcher and postprocessor and wondering if they can be linked better to make sure a file goes where it belongs.
Finally, I thought setting the episode/file status to "Archived" (as you can see in the screenshot I had all of Season 1 marked as Archived) prevented it from overwriting the files? I thought if you left it as "Downloaded" then it would replace them if it found a better quality, but "Archived" would basically tell Medusa to stop looking for replacements. If not (as it seems), have you thought about adding a status that would do that? Stop Medusa from trying to upgrade/replace files even if it later finds something of better quality if a certain status is set on them?
The text was updated successfully, but these errors were encountered: