AniDB renaming episodes titles as episode numbers

[jcphilips]

When renaming a recently aired episode, the plugin renames the episode title as the episode number.

But when renaming the episode through filebot itself the episode title shows up fine.

Only seems to happen when anidb is the selected database.

[Laharah]

I couldn't replicate this:

The only differences that I noticed about your setup was

1. It was on windows, which shouldn't matter

2. Your Filebot Version is listed as 4.8.4

I'm not entirely sure where you got that from since the newest version I could find on filebot.net is version 4.8.2

The other thing that you might try is clearing your cache. It should be located at AppData\FileBot\Cache. An old cache might be getting hit when you do a rename, while -list probably avoids the cache and goes to an actual lookup.

If you wanna test the actual command that Dry Run calls I believe it would be

filebot -rename --action test --db AniDB --format '{primaryTitle} - {sxe} - {t}' --order absolute --lang en -non-strict -r "{PATH}".

Maybe that will let you see the same result in filebot. Ultimately whatever filebot gives back is what the plugin renames to.

[jcphilips]

Version 4.8.4 seems to be the version for the application on the windows store which is where I downloaded filebot from. So I just tried what you suggested with something I just downloaded 5 minutes ago.

I tried the dry run command and got this.

Rerunning the dry run in the extension after the running it in terminal gives this.

As you said, it does seem to be a cache problem but what I don't understand is why doing it in filebot itself or terminal makes it rename like usual but it doesn't work for the extension when they're running the same commands.

[Laharah]

Hmm. That is weird behavior. You may have just hit a cache timing and got lucky, but it's unlikely. Is it possible you have 2 versions of FileBot installed? Check and see if running filebot -verson gives you the same string that at the top in the rename window.

Either way I'd recommend deleting your cache files. According to the forums the windows store version of filebot stores its data at %USERPROFILE%\AppData\Local\Packages\PointPlanck.FileBot_*\LocalCache\Roaming\FileBot Just delete the cache directory and it should clear it.

[rednoah]

FileBot 4.8.4 is indeed the Windows Store version. My first though though was caching as well.

Let's try to clear the cache and see what happens: https://www.filebot.net/forums/viewtopic.php?f=3&t=1996

Also, make sure you don't have multiple versions of FileBot installed, which would explain inconsistent behaviour.

[jcphilips]

@rednoah CLI returns just the windows version I tried a couple of dry runs after clearing cache using filebot -clear-cache and I haven't been able to reproduce the issue. Hopefully that was the issue and it isn't something else but if I manage to reproduce the issue again I will update.

[Laharah]

I'm gonna close this issue as fixed. Feel free to re-open if you run into the same problem again.

[purposelycryptic]

Came across this in a Google search, and while I realize the issue has been marked closed for over 2 months, I just thought I'd add, for anyone running into the same issue, that this is indeed almost certainly a cache issue. AniDB has very low rate limits when it comes to pulling metadata, so a lot of data ends up being cached to avoid bans, and, additionally, sometimes what you see on the site hasn't quite propagated through the system to the point the API is pulling from, especially if you are renaming files directly after RSS release - unless someone has updated an episode name pre-release, the system default name is just "Episode X", and it can take a bit to update.

I've had the same experience fairly consistently using Hama on Plex, the Anime Plugin on Emby, AniAdd, AOM, WebAOM and Shoko's renamer - frequently enough that I actually rewrote my AniAdd script to not move files to the destination folder unless all metadata values were properly available.

I'm neither a mod nor developer at AniDB, just an avid fan that tries to correct incorrect/incomplete/missing metadata on the site whenever I see it, so this explanation may not be 100% accurate, but it matches all my findings over the years. Hopefully this post isn't a bother, but every time I see a thread like this, I can't help but think of this: