Absolute numbering with specials mapping issue impacting One Piece TVDB4

crazygambit commented 5 years ago

I know this has been brought up before, but there hasn't been an acceptable solution yet for One Piece with TVDB4. The culprit is episode 590, which was a special.

https://github.com/ZeroQI/Hama.bundle/issues/264

Here the proposal was to use a folder with an offset, but that messes up with the seasons' cut off episodes (this is particularly important now that a new arc is starting). Renaming episodes is a no go. Sonarr is getting the correct episodes, having to rename them "wrong" just to get them to play nice with HAMA seems like the wrong way to go.

https://github.com/ZeroQI/Absolute-Series-Scanner/issues/194

Here some solutions were proposed, but I don't think anything came out from them. Given One Piece is hugely popular and the show used as an example for TVDB4 in the readme, it's kind of a bad look that it doesn't work. And it's so close to being perfect too! The idea to use arcs as seasons is absolutely fantastic, much better than the mess that is the TVDB order and something that to my knowledge no other Agent can do, on any platform. I think it's worth revisiting this, particularly now that after a couple of years a new arc is starting, and a lots of people might realize they have the wrong seasons (like I did, I didn't even notice the episodes were wrong before Plex mistakenly started the new season ahead of time).

TLDR: TVDB4 is AWESOME, but there's a bug on One Piece a hugely popular show and the example used on the readme, so it might be worth to fix it.

EndOfLine369 commented 5 years ago

@sven-7, please fix the mapping for everyone we already discussed and you fixed for yourself. https://github.com/ZeroQI/Hama.bundle/pull/293#issuecomment-478372618

sven-7 commented 5 years ago

Done, @EndOfLine369. Apologies for not changing it in the master - I was experimenting with it still and forgot to submit the mapping I settled on.

@crazygambit I'm not a fan of the solution myself either, but the change I submitted has been working for me. I think it would be a major overhaul to accommodate specials with absolute numbering. There are a handful of other shows out there with it, but I think One Piece tends to be the only one that most people would notice.

EndOfLine369 commented 5 years ago

Thanks @sven-7, nw on the master update. I've actually noticed and corrected in my local code an inconsistency seen in ASS/HAMA.

ASS use of anime-list-custom.xml is found from direct library root/subfolder placement. Seems HAMA doesn't use the library placed files. It uses only one global file in the DataItems\AnimeLists\anime-list-custom.xml file. You probably noticed this in your local testing. My update will ignore that DataItems file and follow the same as ASS for looking for local mapping. Will be committing it soon.

EndOfLine369 commented 5 years ago

Committed in https://github.com/ZeroQI/Hama.bundle/commit/8545ed70d5421b0deedd150f393861ee91cbf516 HAMA will now look for 'anime-list-custom.xml' in the library like ASS does. I see your thumbs up @ZeroQI, take a look. Let me know if any concerns in how I did it.

sven-7 commented 5 years ago

Awesome - I'll give it a test drive.

DarthKnight12 commented 5 years ago

the change to the xml file is not really a fix per se as it still incorporates the actual offset method (renaming the episodes after 590 using -1 per episode) and to be honest i don't know if its worth the hassle to revamp the entire scanner just to fix the, will all due respect, stupid offset introduced by thetvdb

crazygambit commented 5 years ago

the change to the xml file is not really a fix per se as it still incorporates the actual offset method (renaming the episodes after 590 using -1 per episode) and to be honest i don't know if its worth the hassle to revamp the entire scanner just to fix the, will all due respect, stupid offset introduced by thetvdb

To be clear, sometimes I'm not a fan of the TVDB's decisions on some shows and I'm definitely not a fan of the people running the site, but I think this time they got it right.

Episode 590 was the third crossover with Toriko, episodes 492 and 542 are simply listed as regular episodes, so I don't know why 590 caused so many problems, since obviously it should be treated the same as it was aired at the regular time slot after episode 589. For some reason the TVDB decided to omit that episode for SxxExx numbering, but they do recognize it for it's absolute numbering, which is the key. The scene also recognized 590 as a regular episode (as it should be), so for once the TVDB and Scene agree!

When those 2 entities agree on something, I believe we should follow suit. The latest episode is 879 - "To The Levely! Gathering Of The Straw Hat Allies!". The TVDB and Scene agree on this, there's no reason for the Agent to show that episode as "Sabo Goes Into Action - All The Captains Of The Revolutionary Army Appear!" which hasn't aired yet.

If I use TVDB3 instead of TVDB4 the show maps perfectly, which proves the TVDB got it right this time (even though deciding episode 590 was a special, while 492 and 542 are not is at the very least weird and most likely wrong) when using absolute numbering it works.

TVDB4 is such a great idea for these types of shows though, I'd really like to be able to use it. I think the fix should be to treat episode 590 as a regular episode just like 492 and 542. That would solve all the issues with this show.

sven-7 commented 5 years ago

TVDB4 is such a great idea for these types of shows though, I'd really like to be able to use it. I think the fix should be to treat episode 590 as a regular episode just like 492 and 542. That would solve all the issues with this show.

Have you submitted a request on the TVDB forums? They aren't being consistent, as you pointed out, but I fear that may result in them changing 492 and 542 to specials versus regular episodes instead of 590 to a regular episode. I feel like that will result in worse changes. The argument should be for them to be consistent and list it as a regular episode like the first two. AniDB treats it as one, so hopefully they'd listen, but I don't know that it would pass.

crazygambit commented 5 years ago

TVDB4 is such a great idea for these types of shows though, I'd really like to be able to use it. I think the fix should be to treat episode 590 as a regular episode just like 492 and 542. That would solve all the issues with this show.

Have you submitted a request on the TVDB forums? They aren't being consistent, as you pointed out, but I fear that may result in them changing 492 and 542 to specials versus regular episodes instead of 590 to a regular episode. I feel like that will result in worse changes. The argument should be for them to be consistent and list it as a regular episode like the first two. AniDB treats it as one, so hopefully they'd listen, but I don't know that it would pass.

Yeah, I definitely think contacting the TVDB for anything would be a mistake. They are much more likely to ruin everything than to try to find a solution. Right now 590 is considered as an episode for absolute numbering, which is why TVDB3 works (at least as far a I remember, I really don't want to change back to test since I just got my season posters just like I want them). The problem I believe is that TVDB4 doesn't actually use the TVDB to get the episode numbers. Sonarr for example correctly skips 590, so 589 is Worst Of The World - The Scary Scientist Caesar and the following episode: "Chopper Enraged Master's Tyrannical Experiments" is correctly parsed as 591. Maybe HAMA could use thexem.de for its mapping like Sonarr does.

sven-7 commented 5 years ago

Yep - I'm with you there. It'll likely get a lot worse with their input.

As a side note: I did notice that if TheTVDB doesn't have a description (i.e. they did not for abs 879) then it'll pull the AniDB one....but because we are at a one episode offset, it pulls the wrong one (pulling 878 from AniDB where it should be 879)...looking like this:

Here is the json for 590, btw.

{"data":{"id":4543896,"airedSeason":0,"airedSeasonID":31892,"airedEpisodeNumber":25,"episodeName":"Dream 9 Toriko \u0026 One Piece \u0026 Dragon Ball Z Chō Collaboration Special!!","firstAired":"2013-04-07","guestStars":[],"director":"","directors":[],"writers":[],"overview":"Featured characters of One Piece, Toriko and Dragon Ball enter the IGO tournament in order to gain the Carat meat, which is said to be the most tasteful in the world. However, it leads in a tie between Goku, Toriko and Luffy. Meanwhile, Zoro, Zebra and Vegeta meet accidently in a remote part of the race, and start fighting.","language":{"episodeName":"en","overview":"en"},"productionCode":"","showUrl":"","lastUpdated":1520400903,"dvdDiscid":"","dvdSeason":null,"dvdEpisodeNumber":null,"dvdChapter":null,"absoluteNumber":590,"filename":"episodes/81797/4543896.jpg","seriesId":81797,"lastUpdatedBy":410201,"airsAfterSeason":null,"airsBeforeSeason":16,"airsBeforeEpisode":12,"thumbAuthor":385352,"thumbAdded":"","thumbWidth":"400","thumbHeight":"300","imdbId":"","siteRating":9.7,"siteRatingCount":3}}

ZeroQI commented 5 years ago

The issue is sometimes the absolute episode needs to be ignored, sometimes it needs to be integrated (depending if anidb has it or not).

tvdb4 doesn't use absolute numbering, just take the season episodes in sequence
TVDB5 however dos remap the TVDB numbering to be displayed as TVDB absolute numbering but take tvdb numbering.

Two solutions:

we use tvdb6 for a tvdb4 mode using tvdb absolute numbering instead of just the eps in sequence ? should be simple enough in principle, the scanner
we use mapping files to figure out and change TVDB 4 mode.

Series that span multiple seasons on theTVDB.com may be marked as 'a' if the absolute episode numbering is defined and matches AniDb.net.

  <anime anidbid="69" tvdbid="81797" defaulttvdbseason="a" episodeoffset="" tmdbid="" imdbid="">
    <name>One Piece</name>
    <mapping-list>
      <mapping anidbseason="0" tvdbseason="0">;1-3;2-9;3-10;4-14;5-28;6-0;7-0;8-0;9-0;10-0;11-0;12-0;13-0;14-0;15-0;16-23;17-24;18-29;19-30;20-32;21-31;22-0;23-33;24-35;25-37;26-38;27-0;</mapping>
    </mapping-list>
  </anime>

So... shall we have tvdb absolute numbering supported if defaulttvdbseason=='a' and normal numbering otherwise ?

sven-7 commented 5 years ago

I think back when tvdb4 was introduced, it was based off of TVDB absolute numbering. Considering it's a TVDB mode and described as using absolute, it might make sense to use that again?

Depending on how much difficulty if will be, might not be a bad thing to test?

crazygambit commented 5 years ago

I think back when tvdb4 was introduced, it was based off of TVDB absolute numbering. Considering it's a TVDB mode and described as using absolute, it might make sense to use that again?

Depending on how much difficulty if will be, might not be a bad thing to test?

I'd just like to point out I was wrong in my previous assertion that TVDB3 was working fine. I figure out how to make a dummy copy of my One Piece folder and I tested it on another library. TVDB3 has indeed the same issue of being 1 episode off. I'm thinking the solution might be to use thexem.de to handle the mapping between Scene and TVDB (it was it was created to do) though I think it has a issues on a few shows and I have no idea how hard or how easy it would be to actually implement since I can barely code my way out of a wet paper bag (and need copious help from StackOverflow to manage even that).

ZeroQI commented 5 years ago

@crazy gambit We already have anidb to tvdb mapping both ways. If the scene doesn't match metadata then scene numbering needs changing. Although in the scanner we could do a transparent translation, let's leave that for latter. @sven-7 You are correct and i need to find back why it was changed so we compare both example to make them both work if possible.

sven-7 commented 5 years ago

@ZeroQI - okay! I'm not sure when it was, but I could try looking back as well. I think it was when the major overhauls started sometime last year, but I could be wrong.

crazygambit commented 5 years ago

@crazy gambit We already have anidb to tvdb mapping both ways. If the scene doesn't match metadata then scene numbering needs changing. Although in the scanner we could do a transparent translation, let's leave that for latter.

That is not the way. The TVDB might be able to have that luxury, because their focus is different and they're essentially a monopoly. People put up with it, but the moment a compelling alternative comes I see a lot of people leaving it behind. Plus their purpose is just to present data, not scan it into an app while collect metadata on it.

Nearly 100% of the content the users of HAMA have (particularly currently ongoing shows) will come from scene releases. It is absolutely vital that ASS and HAMA can correctly parse the scene naming and numbering conventions rather than specific databases like TVDB or AniDB. If there's a discrepancy the one that should win over is the Scene IMHO.

I used to manage my database in Kodi before moving it to Plex for a variety of reasons. By writing a regex for Absolute Numbering, I could get Kodi to behave relatively well with Anime, that was in part because there was a thexem.de scanner, which takes care of the discrepancies between scene, TVDB and AniDB. I don't know if that's what you currently use to do the mapping for TVDB with regards to AniDB. If not it might be worthwhile looking into that. It may solve issues like this that could be happening on many shows at the moment, since I'm not convinced the current mapping is too effective. Like for example in Sword Art Online with tvdb3 episode 51 is "Underworld" (correct) while on tvdb2 it's "Demon Tree" which is actually 52. And that was a show I just happened to notice had a mistake by chance. If I tested all my shows I'm sure more inconsistencies would show up.

Still, I think you're doing a wonderful job and it would be great if these kinds of issues could be resolved in a permanent way going forward.

sven-7 commented 5 years ago

I think either reverting to tvdb2/3/4 to using the true absolute number field would help remedy a lot of the current issues.

The issue with One Piece did not exist in tvdb3 or 4 before this change was made. I don’t think it was intentional, so hopefully by reverting back to using that we can move forward.

I also noted SAO in a separate issue. I think there are a lot of shows that have specials with absolute numbering — would be awesome if ASS and HAMA could accommodate those.

EndOfLine369 commented 5 years ago

Indeed, we use to try and calculate our own absolute number or use TVDB's. @ZeroQI, purposely removed this usage from tvdb2/3/4 in his redesign and went live last June. https://github.com/ZeroQI/Absolute-Series-Scanner/issues/185#issuecomment-429638101

We repeatedly had issues of people messing up the absolute numbering in TVDB which we then would not be able to reliably use for any placement. So I agree with ZeroQI that it was better to not use it then use bad absolute numbering. EX https://github.com/ZeroQI/Absolute-Series-Scanner/issues/143

sven-7 commented 5 years ago

Seven Deadly Sins is another show that has absolute numbered episodes, that are specials.

@EndOfLine369 I think the biggest issue, in my experience, with TVDB messing up absolute numbering was it being blank. For example, whens someone added the newest episode they left the absolute field blank. Then ASS would result to pushing it all into one season. I think those are sortable/fixable issues on the TVDB side.

crazygambit commented 5 years ago

Indeed, we use to try and calculate our own absolute number or use TVDB's. @ZeroQI, purposely removed this usage from tvdb2/3/4 in his redesign and went live last June. ZeroQI/Absolute-Series-Scanner#185 (comment)

We repeatedly had issues of people messing up the absolute numbering in TVDB which we then would not be able to reliably use for any placement. So I agree with ZeroQI that it was better to not use it then use bad absolute numbering. EX ZeroQI/Absolute-Series-Scanner#143

That's very interesting, so again I have to ask, have you guys considered using http://thexem.de/ ? It was created for the specific purpose of mapping the differences between Scene, AniDB and TVDB numbering and naming of the shows. Like the TVDB it can be modified by users (but registering can be a pain). Kodi has a TheXem add-on that uses that site to scan a show and it worked well, so it might be useful to take a look at it.

ZeroQI commented 5 years ago

It is complicated enough to map between anidb and and tvdb numbering to have to consider also scene numbering...

Anidb and xmaster numbering seem identical for one piece [http://thexem.de/xem/show/4468] so i cannot see any benefit for that serie.
We could do a scanner mode to translate scene discrepancies seamlessly that i can consider but we need a few case scenario implying it is necessary. xema2-xxxx and xemt1-5-xxxx and it translate to anidb/tvdb modes and we can use the same id given... It's a scanner feature request... Is there that many scene discrepancies ?

We can switch to using absolute numbering to avoid matching issues but if specials are missing in thetvdb numbering.

@sven-7 was the change on scanner, agent or both ? i know can't find it. i recall there was a reason for it with specials on some series but cannot recall which

sven-7 commented 5 years ago

@ZeroQI -- I looked back and here are some scanner issues for reference:

https://github.com/ZeroQI/Absolute-Series-Scanner/issues/77 https://github.com/ZeroQI/Absolute-Series-Scanner/issues/82

EndOfLine369 commented 5 years ago

FYI on removals of this logic from ASS/HAMA. ZeroQI/Absolute-Series-Scanner/commit ZeroQI/Absolute-Series-Scanner/blame ZeroQI/Hama.bundle/commit ZeroQI/Hama.bundle/blame

ZeroQI commented 5 years ago

@EndOfLine You found it!!! https://github.com/ZeroQI/Absolute-Series-Scanner/commit/565f3b4ce804f4bbcc2708f394668415c4edfd7a#diff-edf9a02ffa5a0496c5247e048b83f667L464

Mapping needs to be perfect between anidb and tvdb and When Scudlee mapping have when "defaulttvdbseason"="a" it uses tvdb absolute number episode index and won't match with current code, so we need to revert to using the tvdb absolute numbering index, no other choice is there for consistent metadata across both sources

Some series following this change (back) might stop matching meta propertly if following the episode in sequence and not the tvdb abs episode index when TheTVDB specials have an absolute number assigned.

If that is the case we need examples

tvdb2/3 and especially 4 follow abs numbering so could be impacted, and will have to follow AniDB abs numbering but that should make it more scene compatible

          absolute_number = episode.xpath('absolute_number')[0].text if episode.xpath('absolute_number')[0].text else ''
          if absolute_number:  tvdb_mapping[int(absolute_number)] = (int(SeasonNumber), int(EpisodeNumber) if source=='tvdb2' else int(absolute_number))

sven-7 commented 5 years ago

@ZeroQI - Does the latest commit address the One Piece issues discussed above? I did an initial test and it did not seem to result any differently regarding how the absolute numbering is done for OP.

crazygambit commented 5 years ago

@ZeroQI - Does the latest commit address the One Piece issues discussed above? I did an initial test and it did not seem to result any differently regarding how the absolute numbering is done for OP.

I just updated everything and I can confirm that the numbering error in One Piece persists on TVDB4 (and TVDB3 as well).

ZeroQI commented 5 years ago

Mapping needs to be perfect between anidb and tvdb and When Scudlee mapping have when "defaulttvdbseason"="a" (big series impacted, using tvdb4 predominently) as it uses tvdb absolute number episode index and won't match with current code, so we need to revert to using the tvdb absolute numbering index, no other choice is there for consistent metadata across both sources

      if episode.xpath('absolute_number')[0].text:  absolute_number = episode.xpath('absolute_number')[0].text
      else:                                         absolute_number += 1

But that would impact tvdb 2 and 3 mode only need to look more at the code

sven-7 commented 5 years ago

Well - the absolute numbers in TVDB do lineup with AniDB...but because one of those is a special, it is the issue. I think your conclusion is correct.

architdate commented 4 years ago

Something that else that I noticed with One Piece metadata, there are issues with TVDB3 as well (duplicated images and incorrect titles in the latest seasons) Attached screenshots below

Here, episode 890 and 891 have a different name and 892 episode name didnt even get fetched from TVDB (my animetitles.xml is updated)

This is also seen in other seasons (the metadata pic is repeated twice even though the episode is different and the name is different)

Feel free to let me know what data you would need to debug this! Thanks!

sven-7 commented 4 years ago

Yeah. This is related to the absolute mapping issues in this thread. As far as I know it’s still unresolved.

architdate commented 4 years ago

Interestingly enough, the description of the episode is correct even though the name and the image is wrong for episode 890

This should be the correct data here:

architdate commented 4 years ago

Yeah. This is related to the absolute mapping issues in this thread. As far as I know it’s still unresolved.

Ah I see, this wasnt an issue before it seems. I updated my Hama today after a month or so and found this issue!

architdate commented 4 years ago

Also, it may be a good idea to change the name of this issue to "Absolute Mapping Issues" since it isn't really just a One Piece or a TVDB4 problem :)

ZeroQI commented 4 years ago

In TheTVDBv2.py Line 132, please replace if season!='0': abs_number = abs_number + 1 with if season!='0': abs_number = Dict(episode_json, 'absoluteNumber', default=abs_number+1) respecting the spaces (beware on notepad++ it uses tabs separation by default, change to 2 spaces per indent and spaces instead of tab)

Please test and report. If it solves i will include in the master code

It should solve non-specials issue

Specials should not get the abs number. if so replace the code starting line 132 with this one simply removing season 0 tests and ep 0 to absolute number if doesn't exists:

  abs_number = Dict(episode_json, 'absoluteNumber', default=abs_number+1 if season!='0' else 0)
  if anidb_numbering:
    if Dict(mappingList, 'defaulttvdbseason_a'):  season, episode          = '1', str(abs_number)
    else:                                                         season, episode, anidbid = anidb_ep(mappingList, season, episode)
  elif metadata_source=='tvdb3':  
    episode             = str(abs_number)
  elif metadata_source=='tvdb4':  
    ms, usl                         = Dict(mappingList, 'absolute_map', 'max_season'), Dict(mappingList, 'absolute_map', 'unknown_series_length')
    if ms and usl:  season, episode = Dict(mappingList, 'absolute_map', str(abs_number), default=(ms if usl else str(int(ms)+1), None))[0], str(abs_number)
    if season not in media.seasons or episode not in media.seasons[season].episodes:  #tvdb4 with custom season folder mapping
      for s in media.seasons:
        if str(abs_number) in media.seasons[s].episodes:
          season, episode = s, str(abs_number)
          break      
  elif metadata_source=='tvdb5':  
    episode, abs_number = str(Dict(episode_json, 'absoluteNumber') or abs_number), int(Dict(episode_json, 'absoluteNumber') or abs_number)

architdate commented 4 years ago

Replaced line 132 with if season!='0': abs_number = Dict(episode_json, 'absoluteNumber', default=abs_number+1)

here are the results. 1) Episode 890 naming was fixed

2) Episode 892 was still not fetched (TVDB has the entry)

3) There are still repeated thumbnails since episode 590 (please see image below)

For reference, this is my directory structure:

Also 590 is actually the Toriko special as specified before

591 is the correct name and image, its just that after 590 images are constantly duplicated. Future naming is also spot on based on wikipedia:

What the ideal fix would be in this case is for the collaboration special to have its absolute episode number but retain its correct name and for the images to not get messed up after episode 590. Also a fix for TVDB fetching for episode 892 would be appreciated :)

Sorry for the long post, I just wanted to document everything so you can see it all in once place instead of having to scroll up and down the issue thread! Please let me know anything else you would like me to try out, happy to help @ZeroQI

architdate commented 4 years ago

Also some extra info - My directory structure, follows wikipedias seasons as opposed to TVDB seasons. But TVDB 3 allows me to have abs number episodes in each of the seasonal folders and it parses it correctly in Plex according to my directory structure.

Also the 892 episode is marked as season 21 according to TVDB while its in S20 acc to wikipedia (and so its in the S20 section for me too) I dont know if that is affecting the data fetching, but that may be something to consider. (Although it really shouldnt, considering its based on absolute episode numbers and not seasons)

ZeroQI commented 4 years ago

@architdate wikipedia numbering is not supported. If there is a difference it will give either no or metadata from another episode.

you use tvdb3 which was meant to rename AniDB absolutely numbered series in tvdb strict numbering or use folders alredy numbered as such.
You should use tvdb4 which allows absolutely numbered with ANY season setup
Rather than including screenshots of your directory structure, include the filelist log.
Once a wrong image is there, i am not sure the agent can overwrite it, and screencaps are managed in code further down. The agent logs would give the link to the screen cap and this is the one that matter.

Ideally tvdb3 mode at scanner level should be renamed to tvdb4 the same way anidb2 mode is changed to tvdb mode there, and tvdb3 mode code purged from hama then both for simplicity and as seasons won't matter anymore if all eps keep absolute numbering in season folder, but no time to code that right now, bugs needs resolving first...

Since the mapping file in defaulttvdbseason='a' use tvdb absolute number, it needs fixing... Can someone with proper absolute numbering in tvdb4 mode test the second code i pasted? it supports meta for specials

sven-7 commented 4 years ago

I’m traveling in Europe for a few days. If I can get proper access to my server, I’ll give it a shot. Otherwise it might be a few days. Will try tonight.

architdate commented 4 years ago

@zeroqi Ah, yes I'm aware that Wikipedia numbering isn't supported, it's just my directory structure that allows me to view the the episodes in that order. AniDB absolute numbered episodes is fine too! (Ep 590 in AniDB is named Histories Strongest Collaboration! The Glutton of the Abyss ) Also tvdb3 is fine for me as of now since my folders are named seasonally so Plex picks it up as how I have seasonally separated it rather than how tvdb separates it

Also would love to give u the agents filelist log. Would you let me know the location of the log and what you would need me to do before logging a metadata refresh? (Deleting previous log etc etc?)

architdate commented 4 years ago

Also regarding the image, I actually had correct images for every episode before (when my hama.bundle was from 2018). An update to the latest commit changed it up and the images got messed up. So am assuming that the agent should be able to overwrite it. If not I'm assuming that unmatching the series and then force matching it to tvdb3/4 using fix match should do the trick (hopefully)

architdate commented 4 years ago

@ZeroQI Ah, I found the logs in question. Have attached the filelist log and agent-update log The weird thing is that the logs do have different episodes being logged, its just that plex doesnt update the episodes with the new jpeg image.

agent-update log doesnt seem to be able to fetch 892. and 590 (which is understandable for tvdb3 since there is no tvdb entry for the special). Also the correct images get all downloaded to TheTVDB/episodes/<id>.jpg, they just dont get applied properly on Plex.

Here are the logs in question: One Piece.agent-update.log One Piece.filelist.log

ZeroQI commented 4 years ago

Are you using the second code i pasted? It should manage specials

architdate commented 4 years ago

Nope, i just modified line 132. I'll use the second code snippet and let you know the output

architdate commented 4 years ago

Sorry for the delay, @ZeroQI , but the code snippet didnt fix the issue

(I replaced line 132 to line 142 with your code and after restarting the server, i refreshed metadata)

ZeroQI commented 4 years ago

can i have the series update log? ai see the screecaps duplicatex. anything else wrong?

architdate commented 4 years ago

Well, the special isnt renamed (episode 590) and it also didnt fetch 892 and 893. Thats all that is wrong apart from the screen cap duplication.

Agent Update Log: One Piece.agent-update.log

sven-7 commented 4 years ago

Okay -- I was just able to test this. 590 is showing up in-season, as expected with the second set of code you posted. The title and description came thru accurately. The screenshot is there, but Plex seems to be doing something weird. I think it may be because I have two libraries with One Piece in it. So maybe it loaded the data twice? Each episode seems to be in there twice.

Otherwise -- to me this seems to be acting as desired.

I also did this with a local mapping file because the one on Git has a one episode offset.

Here are my logs and file structure.

logs.zip One Piece [tvdb4-81797].zip

Edit: I'm going to try clearing out all of my metadata and add it fresh in a new test library.

sven-7 commented 4 years ago

Update - after trying fresh, it did not change anything with the screenshots. Many are still doubling up and some are wrong (892). It's very close -- just seems to be an screenshot/images issue.

Logs attached.

_Logs.zip

architdate commented 4 years ago

TVDB3 with the latest code doesnt fetch the special title properly in my case. Apart from that its also a images issue in my case. Also 892 and 893 are not being fetched still. Is that the case in tvdb4 too? @sven-7

ZeroQI commented 4 years ago

@sven-7 if it's only the screenshots it's good

screenshots duplicated

590-591 - 590 show wrong screenshot
592-593 - 592 show wrong screenshot
596-597
599-600
602-603

590 'thumbs': {'https://thetvdb.plexapp.com/banners/episodes/81797/4543896.jpg': ('TheTVDB/episodes/4543896.jpg', 1, None)} 591 'thumbs': {'https://thetvdb.plexapp.com/banners/episodes/81797/4552175.jpg': ('TheTVDB/episodes/4552175.jpg', 1, None)} 592 'thumbs': {'https://thetvdb.plexapp.com/banners/episodes/81797/4552176.jpg': ('TheTVDB/episodes/4552176.jpg', 1, None)} 593 'thumbs': {'https://thetvdb.plexapp.com/banners/episodes/81797/4552178.jpg': ('TheTVDB/episodes/4552178.jpg', 1, None)}

Hama agent give correct meta but cannot changer thumbnail from bad code before Plex Dance necessary to fix

ZeroQI / Hama.bundle

Absolute numbering with specials mapping issue impacting One Piece TVDB4 #298