VGMdb Beta Bug Reports

[Myrkul]

Posting this here to avoid making a new post..

Seems like the explanation of the color coding is now incomplete

I see "Other" is white, seems like it is for Publication ?
Seems like there is a grey color for Drama (drama & radio shows)


Would be cool if we could search for these sub-classifactions on the advanced search too. (anime only, demo scene only.. etc..)

^_^

[Ira]

The tabindex of either the login form in the top right or the login form that shows up on board pages should be changed.
Presently all the elements in them have the same tabindex value which results in focus jumping between the two forms when tabbing (101-101-102-102-etc.)
Alternatively, you could remove the login form from board pages completely because it's redundant.

[Kaleb.G]

There's a bug when you receive a PM while viewing the main page of the site (main.php). If you follow the JavaScript prompt to open the PM in a new window, the URL it tries to go to is wrong. It starts with something like http://vgmdb.net/album/ instead of http://vgmdb.net/forums/.

[Liontamer]

Apologies for a potential repeat issue, but when Sale sites have more than one line for the title, they end up squished together and overlapping.

e.g. http://vgmdb.net/album/17601

[Gigablah]

Originally Posted by Liontamer

Apologies for a potential repeat issue, but when Sale sites have more than one line for the title, they end up squished together and overlapping.

e.g. http://vgmdb.net/album/17601

Oh dear

Got it fixed, hopefully. You never know with CSS.

[Revoc]

I think in many cases the titles of sites can be simplified, however. Here for example:

"岩垂徳行 on MySpace Music - Free Streaming MP3s, Pictures & Music Downloads"

"岩垂徳行 on MySpace" or just "MySpace" already work well in my opinion.

[seanne]

Originally Posted by Revoc

I think in many cases the titles of sites can be simplified, however. Here for example:

"岩垂徳行 on MySpace Music - Free Streaming MP3s, Pictures & Music Downloads"

"岩垂徳行 on MySpace" or just "MySpace" already work well in my opinion.

I agree with this, the name of the site in question should be enough in most cases. Makes it look nicer and less cluttered I think.

[Revoc]

If you search for a name that is on the Variations field, this name will appear twice.

http://vgmdb.net/search?q=muroya
http://vgmdb.net/search?q=tsuruya
http://vgmdb.net/search?q=kajiwara

[Ira]

Here's an actual bug that deletes track titles when editing the playlists. Simply put, the function that parses through the text field matches empty lines, which can result in titles being changed to "".

Changing line 27 of the function to

if (fields != 1 && !/^\s*$/.test(match[5])) {

and line 36 to

else if (match[8] != undefined && !/^\s*$/.test(match[8])) {

seems to work (you could just match against empty lines, but I can't think of a good reason to copy over whitespace.)

[Gigablah]

Should it just delete empty lines in the text box before doing the parsing?

Still, I might as well put that fix in. Thanks!

[Ira]

Album pages with requestable tracks cause Firefox's (3.5.8 x86) CPU usage to spike. Seems to be strictly a Firefox issue so it's really a bug on their end, but maybe there's something that could be changed to avoid it?

Edit: Since I'm not half-asleep any more I decided to try it in safe mode and there's no issues with the page, so I want through my add-ons and the culprit is XHTML Ruby Support, even though there shouldn't be anything actively using it. Odd.

[Dag]

Not quite a bug but I noticed that in the results pages you can only order in a direction when clicking the catalog/album name/release buttons. I was expecting clicking again would reverse the order, this is quite common.

[Myrkul]

Is it normal we got 2 times the release date mofications on "my submissions"?

(both gives the same changes, but one is with format 2000-01-01, while the other is January 1, 2000)

[Secret Squirrel]

The format for storing the release date got modified, but we still kept the old one in case something went wrong. Now that it's all tested and working properly, we could get rid of the old field.

[Ira]

Not really a bug, but the manner in which users are sorted in the collections list and the member list is inconsistent. The sort method used (from what I can observe) sorts by 'select non-alphanumeric characters, numeric characters, alphabetic characters, all other characters' in that order. The inconsistency arises because the collections list is split into multiple parts which places all non-alphabetic characters into the '#' and the member list is just a single list. What this means is that some users that show up the beginning of the collections list will show up at the end of the member list. Really a small thing, but it threw me off.

[Myrkul]

I got that warning (4 times) in the top of the page of the Approved Scans list (in the staff only moderation queue)

"Warning: Invalid argument supplied for foreach() in [path]/class_base.php on line 502

[Secret Squirrel]

It's be cause of deleted scans coupled with some changes I made. I need to fix that in 3 places.

[Secret Squirrel]

Originally Posted by Myrkul

I got that warning (4 times) in the top of the page of the Approved Scans list (in the staff only moderation queue)

"Warning: Invalid argument supplied for foreach() in [path]/class_base.php on line 502

I put in some code to fix this. Basically, queue entries for deleted items will no longer show in the pending and accepted queues.

[Kaleb.G]

Looks like some odd behaviour here where album scans are uploaded, but none are set as the default.

[Ira]

Originally Posted by Kaleb.G

Looks like some odd behaviour here where album scans are uploaded, but none are set as the default.

Actually, one is set to default. The problem seems to be with how the thumbnails are generated (in this case none were.)

Edit: Yeah, because it's a goddamn bitmap.

[Kaleb.G]

Originally Posted by Ira

it's a goddamn bitmap.

Time for another HD upgrade amirite?

[Ira]

All the information in the second column is being shifted up a row on this organization page (the type is bad?)

[Gigablah]

Oops, fixed it. I'll have to take a look at the CSS later, too.

[Ira]

Not really bugs, but some feedback that you can file away somewhere.
Places where language settings don't work (but should!):
- Aliases on artist pages
- Organizations on the organization page
- Units and organizations on artist pages
- Name on artist (intentional?) and organization pages

Some more language display thoughts:
- Don't italicize the display title, it looks bad (seems to show up when there is no original/romanized title?)
- Avoid having the same title displayed twice. Could probably be fixed by changing how the HTML for album titles is generated. You guys know what this looks like better than anyone, but to make the point, this is what the title looks like on the page for an album with only a display title:

<h1><span class="albumtitle" style="display: none;" lang="en">DISPLAY_TITLE</span>
<span class="albumtitle" style="display: none;" lang="ja"><em> / </em><i>DISPLAY_TITLE</i></span>
<span class="albumtitle" style="display: inline;" lang="ja-Latn"><em> / </em><i>DISPLAY_TITLE</i></span> </h1>

<div style="padding-left: 10px; padding-right: 10px; padding-bottom: 6px; font-size: 9pt; color: rgb(120, 137, 144);">
<span class="albumtitle" style="display: none;" lang="en"></span>
<span class="albumtitle" style="display: none;" lang="ja">DISPLAY_TITLE<br></span>
<span class="albumtitle" style="display: inline;" lang="ja-Latn">DISPLAY_TITLE<br></span></div>

So, if the display is the same as the original or romanized title (or there is no original or romanized title) keep the appropriate (ja or ja-latn) span in the div empty?

[Gigablah]

That HTML code is horribly archaic, and will be removed with extreme prejudice when my time allows. It's only like that due to the way our language switcher works.

[CHz]

I edited this album an hour ago: http://vgmdb.net/album/7754. All I did was add "Guitar: GO" at the end of the notes, but the changelog and my submissions page say that I also changed the release date from December 18 to December 17. The thing is that the album display page still says December 18, as it should, because that's the release date and I didn't change it.

The same thing has happened on just about every album I've edited in the past few days (check my submissions list): it says I've set the release date back a day when I didn't. All of the albums still have the correct release dates on their pages; it's just screwed up in the edit histories.

[Secret Squirrel]

That's because of the server change, and the slightly different timestamp. Luckily, we aren't using that field anymore to store the dates. We just need to clean up that field.

[Gigablah]

To further clarify, the original database stored release dates as timestamps. That was a pretty great idea because it meant we couldn't specify ambiguous release dates and had to work around it with "monthknown" and "dateknown" flags -- plus whenever we changed servers, the generated timestamps would be off by one or two hours and that resulted in all sorts of quirks with sorting, searching, etc.

So when we implemented the new editing interface I finally added a field that stored release dates in YYYY-MM-DD format. The old timestamp is still being used all over the place though, so the field will remain until I rip out every trace of it (probably by today).

[CHz]

Radical. Just glad nothing's broken!

[Ira]

Labels aren't searchable under their unicode/kanji name.