Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Gents,

I find it totally unacceptable that there are NSTL requirements for submission that are not included in "Application Developer's TRUE BREW Test Guide: Requirements and Test Cases". I just had an application rejected because it contained a file with a ".mid" extension instead of ".midi".

Apparently there's an FAQ out there that explains why we shouldn't use ".mid"... but it is neither explained nor required anywhere in the TRUE BREW testing requirements. (Note: the FAQ case-in-point doesn't even apply to this particular app because the file name remains unique despite the BREW 1.X bug.)

Documentation for BREW is fragmented enough as it is. Forcing us to read and comply with various FAQs in addition to normal requirements is just plain silly. FAQs are for people who have QUESTIONS. I had none - my app works fine as submitted.

Please put ALL requirements in one place - "Application Developer's TRUE BREW Test Guide: Requirements and Test Cases."

Hi,
Our application was also cancelled (not failed) for the exact same reason. I too thought that it was an unecessary rejection until I called the nice folks at NSTL, who explained the bug in better detail than is documented on the website.
There are applications in the wild with the .mid extension, so I think they've just recently figured this out and have not had a chance to update the official documentation for this bug yet.

Hi,
Our application was also cancelled (not failed) for the exact same reason. I too thought that it was an unecessary rejection until I called the nice folks at NSTL, who explained the bug in better detail than is documented on the website.
There are applications in the wild with the .mid extension, so I think they've just recently figured this out and have not had a chance to update the official documentation for this bug yet.

Did you have these .MID files inside your BAR file, or did you have these as separate files?

Did you have these .MID files inside your BAR file, or did you have these as separate files?

Separate files. This was for the Toshiba 9500 build, which doesn't support playing sound from a buffer (-- in a bar file)

Separate files. This was for the Toshiba 9500 build, which doesn't support playing sound from a buffer (-- in a bar file)

That's weird--I play MIDIs out of buffers on my 9500 version of Poker Solitaire.

That's weird--I play MIDIs out of buffers on my 9500 version of Poker Solitaire.

Whoa? Really?
Ahhh, I guess I didn't read the datasheet as carefully as I should have. The buffer problem doesn't apply to MIDI files....

Whoa? Really?
Ahhh, I guess I didn't read the datasheet as carefully as I should have. The buffer problem doesn't apply to MIDI files....

Can you point us to the FAQ that contains this point? I recall reading something about making sure the last character was different, but not the second to last...
-Aaron

Can you point us to the FAQ that contains this point? I recall reading something about making sure the last character was different, but not the second to last...
-Aaron

This isn't the last letter of the file name problem. This is a can't play music from a memory buffer problem.

This isn't the last letter of the file name problem. This is a can't play music from a memory buffer problem.

Aaron -
Sadly I don't even know which FAQ it is in. Our test lead discovered the "rule" and informed me so I made the change to the code, but I haven't seen the FAQ myself.
What I was told is that BREW 1.x doesn't load file names correctly - it either drops the last character or it changes it to ~ or something silly like that. So MyApp.MIF and MyApp.MID appear identical to BREW 1.x.
The FAQ case didn't apply to my application, however, because my sound file's name was unique at the first character - it was the only file in the app that started with the letter 't' so it wouldn't have mattered how many characters BREW 1.x mangled as long as it kept the first one.
Dragon -
My MIDI file was also a separate file. No particular reason, I just never bothered putting it in the BAR. It's quite small - only ~500 bytes - so it doesn't really matter where I keep it.

Aaron -
Sadly I don't even know which FAQ it is in. Our test lead discovered the "rule" and informed me so I made the change to the code, but I haven't seen the FAQ myself.
What I was told is that BREW 1.x doesn't load file names correctly - it either drops the last character or it changes it to ~ or something silly like that. So MyApp.MIF and MyApp.MID appear identical to BREW 1.x.
The FAQ case didn't apply to my application, however, because my sound file's name was unique at the first character - it was the only file in the app that started with the letter 't' so it wouldn't have mattered how many characters BREW 1.x mangled as long as it kept the first one.
Dragon -
My MIDI file was also a separate file. No particular reason, I just never bothered putting it in the BAR. It's quite small - only ~500 bytes - so it doesn't really matter where I keep it.

This test should also be part of the next version of the AppSigner application to not even let you submit apps that have bad filenames.

This test should also be part of the next version of the AppSigner application to not even let you submit apps that have bad filenames.

Roadkill - I wonder if your failure is actually a bug in the test script that NSTL runs (it only checks the extensions but doesn't bother with the filenames)...have you tried bringing up the problem with NSTL?

Roadkill - I wonder if your failure is actually a bug in the test script that NSTL runs (it only checks the extensions but doesn't bother with the filenames)...have you tried bringing up the problem with NSTL?

Hi all.
My application was also cancelled for the same reason. I submitted application with separate midi file with extension “mid”, not “midi” and it was cancelled, although the midi file name and application name are total different. In my opinion, this extension shouldn’t be problem in the case when the name of midi file is different of application name. My previous application, which passed testing and has a TRUE BREW tested status, uses a separate midi file with “mid” extension, not “midi”.
Moreover, NSTL cancelled, not my new application, but upgrade of the existing application which has TRUE BREW status and uses the same midi file with “.mid” extension, not “midi”.
It seems that it wasn’t problem before, but now this is a problem. I don’t know why and which document emphasizes this new test requirement.
MisoK

Hi all.
My application was also cancelled for the same reason. I submitted application with separate midi file with extension “mid”, not “midi” and it was cancelled, although the midi file name and application name are total different. In my opinion, this extension shouldn’t be problem in the case when the name of midi file is different of application name. My previous application, which passed testing and has a TRUE BREW tested status, uses a separate midi file with “mid” extension, not “midi”.
Moreover, NSTL cancelled, not my new application, but upgrade of the existing application which has TRUE BREW status and uses the same midi file with “.mid” extension, not “midi”.
It seems that it wasn’t problem before, but now this is a problem. I don’t know why and which document emphasizes this new test requirement.
MisoK

aisaksen -
Our app didn't fail - it was cancelled just like everyone else's who has posted here. That just basically means that you're not even allowed to submit your app, so at least we weren't charged once we complied with their wishes and resubmitted.
I am reasonably certain that the problem, such as it is, resides in NSTL's test script. I don't believe that their test script actually checks for the 1.1 bug at all - it seems to me that they merely check for specific extension names regardless of whether or not those names would actually be a problem. This is undoubtably due to a miscommunication between Qualcomm and NSTL about what, exactly, constitutes the 1.1 bug.
We did talk to NSTL about it. It appears that Qualcomm told NSTL that the issue discussed in the mysterious FAQ is a requirement, therefore they test for exactly the situation that Qualcomm told them to check. I can't really blame NSTL for testing what Qualcomm tells them to test. I do blame Qualcomm, however, for telling NSTL one thing and us another.

aisaksen -
Our app didn't fail - it was cancelled just like everyone else's who has posted here. That just basically means that you're not even allowed to submit your app, so at least we weren't charged once we complied with their wishes and resubmitted.
I am reasonably certain that the problem, such as it is, resides in NSTL's test script. I don't believe that their test script actually checks for the 1.1 bug at all - it seems to me that they merely check for specific extension names regardless of whether or not those names would actually be a problem. This is undoubtably due to a miscommunication between Qualcomm and NSTL about what, exactly, constitutes the 1.1 bug.
We did talk to NSTL about it. It appears that Qualcomm told NSTL that the issue discussed in the mysterious FAQ is a requirement, therefore they test for exactly the situation that Qualcomm told them to check. I can't really blame NSTL for testing what Qualcomm tells them to test. I do blame Qualcomm, however, for telling NSTL one thing and us another.