New language/relation system - Report all bugs here!

[fahrenheit]

on the panels that DerIdiot sugested, i also agree with the ideia of simple and extended file add, but i sugest we split the streams

the user gets to the part of adding streams, and he *clicks* something and a popup opens for him to add a stream, kind of like the wizard thingies of windows:

[V] Add video stream
[A] Add audio stream
[S] Add subtitle stream

then user get a list of the streams added to the anime, and if he so wants he may choose one to remove.

Stream | Type | stuff...
---------------------------------------------------
| 1. Video: video stuff [R]emove
| 2. Audio: audio stream 1 stuff [R]emove
| 3. Audio: audio stream 2 stuff [R]emove
| 4. Subs: subtitle stream stuff [R]emove
---------------------------------------------------

kind of like the way we can handle files in mylist.

On a side note:
this is for epox, petriw and exp
currently we have 3 apis, web, tcp and udp, in the udp front we get a simplified api, which works fine because of that, open to every one to develop, there aren't many reasons for a user to try add files with the udp api.
on the tcp front we get the full blown api, with all the percs and stuff, but only aom gets to access that api, the tcp api is the only that can do creqs on files.
on the web front a user can do all the actions, but interfaces are limited only to the site.
my point is, we currently don't have any way to automate the process of file adding/crequing with any api other than web.
on the other way, i for example use a interface with ffmpeg to get stream info of files, that other than never getting the correct bitrate for files, works fine, i can't interface that information to anidb by no other means other than the web interface, are there any plans to give more access the udp access?
(sorry i'm not up to date with the current stream processing of aom)

[nwa]

- give an error message "We want the pixel resolution aka the resolution the file was encoded in, not the display resolution. The anamorphic flag should be checked when pixel and display resolutions differ. " if (Res. Width == 848 || 852 || ...)

ok forget that, there are encoders who upsize from 720 to 848, I just didn't think anybody would be that retarded


Now, I think we need to make 1 thing clear as soon as possible, if an encode is compeltely hardsubbed, does it need to have any flags checked? I don't think it should, because if you check the karaoke and signs flags, it may seem that it doesn't have the dialogue subs, if you check the styled flag, well that's completely pointless since hardsubs are styled by default even if they're in arial. If the file is hardsubbed, then only adding the sub sream as hard is enough, karaoke and signs etc. are only ment in case the main dialogue is soft subbed and karaoke for example is hardsubbed etc.
http://anidb.info/perl-bin/animedb.pl?s ... 69&nonav=1 <-- kinda ridiculous if you ask me, I mean sure, this way we could see which group made a karaoke and which didn't, but do we really care for that to go into such detail, we mainly want to know whether the encode has soft or hard subs.

[ricce]

Now, I think we need to make 1 thing clear as soon as possible, if an encode is compeltely hardsubbed, does it need to have any flags checked? I don't think it should, because if you check the karaoke and signs flags, it may seem that it doesn't have the dialogue subs, if you check the styled flag, well that's completely pointless since hardsubs are styled by default even if they're in arial. If the file is hardsubbed, then only adding the sub sream as hard is enough, karaoke and signs etc. are only ment in case the main dialogue is soft subbed and karaoke for example is hardsubbed etc.
http://anidb.info/perl-bin/animedb.pl?s ... 69&nonav=1 <-- kinda ridiculous if you ask me, I mean sure, this way we could see which group made a karaoke and which didn't, but do we really care for that to go into such detail, we mainly want to know whether the encode has soft or hard subs.

I don't agree with you...

OK, to add the "styled" i can agree is ridiculous but the other flags sure are usefull. Maybe add a "sup. hard" sub as for softsubs, or add another flag that tell us "no dialog" or "supplement sub" (and remove the "sup. soft" type) to avid confusing when the hard subs doesn't content dialog.

Can you give me any reason for not provide information that can be usefull.... it will not take more server hdd space, a flags variable is always the same size whatever it is set or not.

[Elias]

Minor related bug:
output of ed2kdump adds in filenames (just before extension) additional string: (dub.sub ukn.ukn)

[worf]

all videos were set to 4:3 during the initial conversion even though their real aspect ratio is different. considering the huge amount of files that need to get fixed -> script it :p

704x396 is set to 4:3 instead of 16:9
640x360 is set to 4:3 instead of 16:9
and so on ...

[ricce]

all videos were set to 4:3 during the initial conversion even though their real aspect ratio is different. considering the huge amount of files that need to get fixed -> script it :p

704x396 is set to 4:3 instead of 16:9
640x360 is set to 4:3 instead of 16:9
and so on ...

or:
if(width/height == 16/9 && !anamotphic && !wrong aspect ratio)
set ar = 16:9

[lamer_de]

ATM, there is no easy way to detect if a file is VFR (pretty much the only way to be sure is to extract the timecodes), hence that checkbox will be majorly misused / ignored by 95% of the user population.

CU,
lamer_de

[PetriW]

ATM, there is no easy way to detect if a file is VFR (pretty much the only way to be sure is to extract the timecodes), hence that checkbox will be majorly misused / ignored by 95% of the user population.

We're working on solving that via aom.6.

[aagcnet]

ATM, there is no easy way to detect if a file is VFR (pretty much the only way to be sure is to extract the timecodes), hence that checkbox will be majorly misused / ignored by 95% of the user population.

We're working on solving that via aom.6.

looks like Aom 6 will make us all rehash our files ^^ it was a pain in the butt to reshash like 400 dvds/cds last time i was forced to O_o.

[AOD BOB]

ooks like Aom 6 will make us all rehash our files ^^ it was a pain in the butt to reshash like 400 dvds/cds last time i was forced to O_o.

Go 1.8TB of pure hard drive space

[TeDi]

searching for an anime while not logged in gives you an error page but underneath it still shows a distorted searched anime information

[SinsI]

Well, not exactly a bug but almost as nasty:

Somebody changed a video stream in a file I added, I have no way of finding out - what file was affected by that CREQ, I only see that stream ID, without connection to the file.
That is, this CREQ report is missing file id:

http://anidb.info/perl-bin/animedb.pl?s ... .id=315370

[Der Idiot]

some more sane suggestion for the new interface by pelican. figured it would be best to post that here as well.

If someone feels up to the task to create a presentation of this html + js it would surely help to bring the point better across.

Code: Select all

        Type:   [Audio/video]
                |Subtitles  |
                +-----------+
        ED2k:   [________________________________]
        MD5:    [________________________________]
        SHA-1:  [________________________________________]
        CRC-32: [________]

If no scripting available, a note here saying to ignore these for
subtitle files.  Otherwise, only display them when a/v is selected:

        Configuration:
none    +-------------------------------------------+
sele-   | Custom                                    |
cted    | Japanese audio, english subtitles         |
        | Japanese/english audio, english subtitles |
        | Japanese audio, no subtitles              |
        | English audio, no subtitles               |
        +-------------------------------------------+
        Resolution:
        +------------------------+
        | No video               |
        | Other resolution       |
        | Multiple video streams |
        --4:3---------------------
        | 640x480                |
        | 512x384                |
        | 576x432                |
        | 320x240                |
        --16:9--------------------
        | 1280x720               |
        | 704x396                |
        --Anamorphic--------------
        | 720x480                |
        +------------------------+

If there's no scripting available, stream count inputs and submit button
go here (conflicting stream counts and configuration/resolution result
in an error; the user can avoid this by not filling in one or the
other), and as much information as possible is filled in as default
values on the full form generated by the server, with the appropriate
number of subforms for each type of stream provided.

If "custom" is selected as configuration (and multiple video streams for
the video streams count control) show (after resolution):

        Audio options: <0> Subtitles options: <0> Video options: <0>

When these are changed, show the appropriate number stream subforms
below the stream counts.  All three subform types are demonstrated at
the end of this document.

If the user selects an option other than custom, pretend that he had
selected the appropriate number of audio and subtitle streams streams
and do the same.

If the user selects any resolution, show one video stream subform minus
the resolution fields and show but disable anamorphic along with the
aspect ratio (with the correct values filled in).

Video stream:

        Codec:          [common ones at top]
        Resolution:     [____] x [____]
        Bitrate:        [____]
        ( ) Square pixels Aspect ratio: [4:3 ]
        ( ) Anamorphic                  [16:9]
        ( ) Wrong AR                    |etc.|
                                        +----+
        [ ] VFR (Uh, better way to show the relation between these two?
                Frames per second: [__]      This is kind of backwards.)

Audio stream:

        Audio type:     [eh, the normal options]
        Language:       [blabla]
        Channels, if you must.
        Codec:          [put the useful ones at the top]
        Bitrate:        [____]

Subtitle stream:

        Language: [options]
        [ ] soft

Add all the silly flags yourself if you like.  You get the picture
anyway.

Don't let the user submit unless something is selected in both
resolution and configuration and there's something in the ed2k
field.  Lame files are an obsolete feature.

[fahrenheit]

kay, based on the things pelican sugested and some of my own, here's my mock-up for the fileadd:

http://pwp.netcabo.pt/fahrenheit/projec ... dfile.html

a couple of notes:

i did not bother with no javascript support, but it's simple, i've mantained the current layout, only things like automatic hiding of stuff, add and remove streams and automatic filling of some data will not work, but even that i can make disapear by generating the buttons and selects trough javascript (thus making them invisible to non javascript users), and adding a simple <noscript> tag somewhere to alert users that they should ignore stuff if doing certain things is easy...

i didn't made any check on things, i don't think any more are needed than the ones currently implemented by the server (if we remove the option of don't input ed2k, i don't know how someone without some trouble can cause havoc.

in the javascript version if we are going to maintain the add multiple streams, exp will have to do some work on the form before sending the data to the server, also some work will be needed server side to update all the selects server-side, (specialy the ones in my functions )

and now, night nigth, this took more time than i was expecting (4hrs to be exact )

Edit: new and revised version:
* javascript aware, only outputs options that have something to do with js if user has it.
* revised the code for the aditional streams, select options get automaticaly copied from the 1st stream version ones.
* if video is vfr, bitrate is grayed out (can't do the oposite for some obscure reason)
* all the buttons *should* work correctly now

Edit2:
* Removed some stuff and added other as per request.
* corrected some bugs.
* rar is now *rar*-converting stuff based on this, next updates will be by him.

[pelican]

Obviously the idea wasn't to be compatible with the current form fields, and the javascript-less versions needs server side code, so you weren't expected to produce that.

It's rather different from what I had in mind, so I'll see about poking it myself a little.