AniDB

Found interesting rename cycle on non-ascii character.

"Silent Möbius" is renamed to "Silent Möbs" and every time when the directory is added with "Add Directory" all files are included again for hashing. It is stored in the dB as: "Silent Möbius", but the display does something like "Silent M||s" in the MyList.

This is likelly caused by the server upgrade over xmas, there was an unintended change in character encoding in the AniDB API which I only noticed just before the last release of AOM (should work in latest).
I suggest you rename your current database file (kowai.dat), then run AOM again and redownload all anime information, this should get the entry to show properly in your mylist, if it doesn't I'll have take a look.

After reload of the database (renaming kowai.dat first) I get this in the Mylist:
.
Database entry is ok.
Renaming is still like: I guess that leads to a name mismatch between 'known' file and 'stored' file.

You get the same problem with UFO Princess Walküre? That's the entry I use to bugtest.

have no copy yet... it is in the queue now..

wow, that has funny characters in epname too... Weiss Kreuz may also have issues...

21/02/2004 23:03:56] - Renamed UFO_Princess_Walküre_-_01_-_Bath_House_Where_the_Maiden_Lives_-_[A-E](6a71bcd8)[AniDB].avi to s:\downloading\UFO Princess Walk? - 01 - Bath House Where the Maiden Lives [A-E](6a71bcd8).avi

It looks like UFO Princess Walkà - 01 - Bath House Where the Maiden Lives [A-E](6a71bcd8).avi on the filesystem.

I'll try the file on local filesystem... To eliminate the fileserver as a cause...

Locally it changes to "UFO Princess Walk� - 01 - Bath House Where the Maiden Lives [A-E](6a71bcd8).avi"

Could be a code page problem? (wonder where on earth you can ask NT version XP what code page it is using on the filesystem....)

Hmmmm.... digging into MSHELP i found an article (Q147438) about filename conversions etc.. Seems NT uses unicode and tries to translate nonunicode names to nearest ascii and back again... Interesting... Maybe something??

The linkt to that article is Q147438

Well, AniDB API isn't exactly helping by having changed character encoding somewhere again.
I think there's nothing wrong with AOM, just with the data suddenly being in a different character encoding again.

AOM only uses unicode file names, this is part of why it doesn't work on win9x.


Edit: This is fixed in the development build. (AOM is running again with new data format, current start time on my computer outside debugger: 5 seconds )

I got the same problem with the release 168 and "Weiss Kreuz Glühen". AOM placed some character in the file name that made it illegible to the mule and prevents further sharing.

The log says
Renamed Weiss Kreuz Gluhen - 01 - White Flames [XF].avi to l:\anime\weiss kreuz gluhen\Weiss Kreuz Gl? - 01 - White Flames [XF].avi

The filename is
Weiss Kreuz Gl� - 01 - White Flames [XF].avi

Any ideas?

FYI, Nausicaä of the Valley of Wind gets renamed to: Nausica⟯f the Valley of Wind. This also causes problems with eMulePlus, when it gets to this file it stops hashing new files.

PetriW wrote:Edit: This is fixed in the development build. (AOM is running again with new data format, current start time on my computer outside debugger: 5 seconds )

So, when are we going to see a new version???

Another solution may be perhaps to remove non-ascii characters from the anidb filenames. Just a thought.

Well... the main rename issues have been solved but there is ONE left (that I know of)

GITS ep 14: "YES" using the characters for Yen, Euro and USD

The rename fails on one or more of these characters.

On a SMB share I see YENYEN
On local disk I see YENEURO

Filing a creq on the EP, say if it goes away.

The renaming problem with weiss kreuz was indeed gone with one of the recent releases.