Aom 0.5.5 released

misc client related stuff

Moderators: AniDB, AniDB API

Andemon
Posts: 117
Joined: Thu Oct 14, 2004 4:12 pm

Post by Andemon »

Then you probably don't have the "Auto update known file data" option enabled.

You need hash them again, I guess. -_-;
e-Viper
Posts: 79
Joined: Mon Jun 07, 2004 12:38 pm
Location: Belgium

Post by e-Viper »

Andemon wrote:(I do feel pretty stupid now for making similar creqs manually in the past, though...)
you shoudn't. this auto creq prolly was created bcs the mods got sick of approving the manuel ones : :D
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

e-Viper wrote:
Andemon wrote:(I do feel pretty stupid now for making similar creqs manually in the past, though...)
you shoudn't. this auto creq prolly was created bcs the mods got sick of approving the manuel ones : :D
No, the feature was added because not enough people do it.
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

PetriW wrote:It should be detailed in a tracker item instead, thus we'll get autogranting.
I'm sorry Petri, but add *what* to the tracker? You just released a client that made over 14,000 creqs in two days, and appear to think we should be manually examining them for your mistakes. Now, I don't mind adding some sense to my automation if you've got known problems, but really the sanity checks needs to be added to AOM, not some temp granting script that was made to deal with the huge mess you caused.

Rar
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

Rar wrote:
PetriW wrote:It should be detailed in a tracker item instead, thus we'll get autogranting.
I'm sorry Petri, but add *what* to the tracker? You just released a client that made over 14,000 creqs in two days, and appear to think we should be manually examining them for your mistakes.
Thank you, can you drop the attitude too please? Yes, they're intended to be inspected.
You should maybe take a vacation soon cause soon there'll be more creqs to inspect and I'll break it to you now... You'll NEED to inspect those too, I'll of course inspect my own files first (and accept help if provided) but in the end it'll go out to more people.
Rar wrote:Now, I don't mind adding some sense to my automation if you've got known problems, but really the sanity checks needs to be added to AOM
No, the sanity checks should be added to anidb, otherwise we can't find what files it doesn't handle correctly. I've already stated there's a new version coming out which should fix some of it.
Rar wrote:not some temp granting script that was made to deal with the huge mess you caused.
I mean you should create an anidb tracker item to get what your script does to be done by anidb itself.
But I guess I'm a jerk for asking you who have already gone through the effort of actually doing enough research to create a script that does automatic granting to add it to the tracker.
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

PetriW wrote:Thank you, can you drop the attitude too please? Yes, they're intended to be inspected.
Attitude? There are 122950 files in anidb atm, even if you're only creqing a small subset of them, it's just stupid to think the two active mods should (or can even) inspect every change. Personally I've been waiting for this AOM for a long time and am very appreciative of your work, but there's no need for you to be an impractical ass.
Anyway, if we start blocking more than a small percent of autocreqs for conformation, it's likely you'll never get any feedback at all. It's one thing for nono and people to autocreq 5000 files, it's quite another to manually check bitrate changes on 500 files. Sure, it's possible there are going to be some errors we don't pick up for a while, but you're probably more accurate than a manual enterer already, so as long as we log the changes I don't see any harm in granting a lot of reqs we can't nessersarily confirm.

Anyway, quite frankly, buggered if I'm wasting a tracker item on 'lock if less than 15 seconds', 'grant if old value was 0', 'grant if change of 1 second', 'message for confimation otherwise'. YOU can create a tracker item for what other checks you think are needed.

Rar
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

Rar wrote:
PetriW wrote:Thank you, can you drop the attitude too please? Yes, they're intended to be inspected.
Attitude? There are 122950 files in anidb atm, even if you're only creqing a small subset of them, it's just stupid to think the two active mods should (or can even) inspect every change. Personally I've been waiting for this AOM for a long time and am very appreciative of your work, but there's no need for you to be an impractical ass.
Anyway, if we start blocking more than a small percent of autocreqs for conformation, it's likely you'll never get any feedback at all. It's one thing for nono and people to autocreq 5000 files, it's quite another to manually check bitrate changes on 500 files. Sure, it's possible there are going to be some errors we don't pick up for a while, but you're probably more accurate than a manual enterer already, so as long as we log the changes I don't see any harm in granting a lot of reqs we can't nessersarily confirm.
It's really beside the point, the whole thing should be handled by autocreqs. I just didn't know Exp was away (when I released the stuff!).
Rar wrote:Anyway, quite frankly, buggered if I'm wasting a tracker item on 'lock if less than 15 seconds', 'grant if old value was 0', 'grant if change of 1 second', 'message for confimation otherwise'. YOU can create a tracker item for what other checks you think are needed.
I don't really know what checks are needed BESIDE those. Those checks have been added to the client. That's why I asked you to add it, I thought you had more.
Anyway, for now until I've got a more reliable version bitrates won't be creqed. Mp3 bitrate in avi is what should be highest prio imho. The video bitrates seem "ok" so far.
Skywalka
Posts: 889
Joined: Tue Sep 16, 2003 7:57 pm

Post by Skywalka »

Errm... so the new AoM Version is banned now?
egg
Posts: 769
Joined: Tue Nov 11, 2003 7:17 am

Post by egg »

Skywalka wrote:Errm... so the new AoM Version is banned now?
Look here.
Devil Doll
Posts: 49
Joined: Sat Mar 26, 2005 1:29 pm

Post by Devil Doll »

PetriW wrote:It's really beside the point, the whole thing should be handled by autocreqs. I just didn't know Exp was away (when I released the stuff!).
Wasn't AOM considered to be helpful for aniDB as a whole? As long as it creates a number of CREQs beyond the ability of the maintenance people handling them, the positive effect of automatically correcting certain errors will be void. I have CREQs with missing screen resolutions or even wrong checksums pending because they're buried amongst a load of these "1 second off" requests (which rar & co. surely can't handle), and I don't consider the current situation an improvement.
So PetriW, please be nice and provide an emergency patch version of AOM (with a different version number identifiable by the server software) that doesn't create CREQs for length differences of 1 second, as the quality improvement of the aniDB content for practical use (by real people) is almost nil while the workload on the maintenance people is huge.

If I were one of the site content maintainers I'd do the following:
  1. Select any user who submitted CREQs.
  2. Start to manually check and commit CREQs sorted by date of submission ascending unless I find the first CREQ with a 1 second length correction.
  3. Stop processing this user at this point, and maybe send him/her a message as to manually revoke all changes of this type; continue at 1.
This would be a way to put the load of submitting that many CREQs onto a lot more shoulders, and help the content maintainers do their work.
We could always submit the "1 second off" CREQs later when more trust in the calculation method has been established (so that they get auto-confirmed by the server); I don't mind rehashing my files once AOM can actually submit as much information as I could enter manually via the HTTP interface (currently I already have information about bitrates, for example, and I can manually handle non-AVI containers; given the recent file releases a full support for OGM and MKV might well be the most important next but one feature for AOM as the market share of AVI files is withering).

AOM will currently create the 1 second length correction CREQs over and over again even it I manually revoked them (I already tried the procedure described above, manually deleted all "1 second off" CREQs only to find them again with a higher time stamp later). This is unfortunate as it means the AOM user has to scan his/her own CREQs again and again (that's the reason of the "sorted by submission ascending" clause above).
Perhaps it might be an interesting idea for the server software to reject creating a CREQ for a file while this file is an element of the "revoked CREQs" list of this user. Unfortunately I can only reset that list as a whole and not delete individual entries from it, so the practical use of such a chance alone wouldn't be that great for the time being.

As for the aniDB site software, it might be a nice additional feature for the CREQ list display to add another column to show a list of the field names affected by the change, and use different colors for adding resp. correcting a field content. This way both the user who created the CREQ and the content maintainer would get an easy overview of the posted CREQs, and the maintainer would get a good impression whether it were useful to start committing the CREQs by a certain user (or maybe even select the "most important" changes, such as checksum corrections, language corrections, screen resolutions, releaser information, ... - all of which are a lot more helpful for the aniDB user than the "1 second off" correction).
Der Idiot
AniDB Staff
Posts: 1227
Joined: Fri Mar 21, 2003 10:19 am

Post by Der Idiot »

manual aom creqs are taken care of by a script rar coded so those are no problem. rar just left for the weekend and as that those creqs won't get done.

using a aom version number thats identical to an already approved version would be
a) something exp would never allow
b) totally against the point of approving every version beforehand.

you may have good intentions with your suggestions, but please leave the modding to the mods we can decide best whats needed and whats not.
the number of creqs is definitely no problem. a real problema are badly done creqs by baka users (no source for date, episode number, official crc and so on)
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

The majority of change requests are not 1 second changes, they are valid length change requests from a previous unset length. This report has been filed to address this:
http://www.anidb.net/tracker/view.php?id=255

Rar said he created a script to handle change requests, thus I didn't change the 1 second thing with the new AoM version.
I also hope you understand that change requests not granted by other mods will be granted by me if needed. If they wanted to they can ignore client change requests, they are clearly marked.
Rar
AniDB Staff
Posts: 1471
Joined: Fri Mar 12, 2004 2:41 pm
Location: UK
Contact:

Post by Rar »

Yeah, script quite happily burnt through about 10,000 creqs, though the nuisance of notifies for users is still unresolved. Current version of AOM is now moved over to approved, so no more manualing until the next version with more stuff, whenever that might be. This time round petri will probably have a better idea of the scale of the beast he can unleash, so we can get prepared beforehand rather than needing to rush a bunch of measures to deal with flood.

Rar
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

Rar wrote:Yeah, script quite happily burnt through about 10,000 creqs, though the nuisance of notifies for users is still unresolved. Current version of AOM is now moved over to approved, so no more manualing until the next version with more stuff, whenever that might be. This time round petri will probably have a better idea of the scale of the beast he can unleash, so we can get prepared beforehand rather than needing to rush a bunch of measures to deal with flood.

Rar
It just took longer than normal but when there's a large change (a new field is a HUGE change) there'll be quite a lot of creqs.
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

Code: Select all

03-08-2005 version 0.5.5.240 ALPHA public release
- PetriW  - Quickfix for special episode numbers. They will be too high but at least the program won't blow up.
Locked