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

Developer

Forums

Forums:

With all the newer BREW 3.x devices coming out that feature memory sizes in excess of 10 MBs, and the time it would take to generate enough Max Files to fill such a memory capacity on handsets (some handsets have memories as large as 80MBs and are growing), is there perchance a way to create a new MaxFileCnt 2.0 that can be set to a higher maximum file size? Perhaps develop a MaxFileCnt strictly for BREW 3.x phones that feature the higher memories?

I mean, it becomes quite tedious to generate 100K files on a device that can clearly hold so many megabytes. If there were a setting for maybe 100K, 500K, 1MB, 5MB, or 10MB file creation sizes, it would make it a lot easier to test MaxFile FS Full conditions on the higher-end devices.

Our only other alternative, at work, has been to manually MaxFile a handset through the AppLoader by either uploading large text files to the device or reinstalling copies of a particularly large application. There has got to be an easier way to test this, since it is TBT/NSTL requirement.

I think most people already have developed they're own versions of MaxFileCount, its been out of date for years, as for one thing it can easily brick a phone, and it can take an hour or so to do its thing on others.
Its not a terribly hard app to write, shouldn't take more than an hour or two.

I think most people already have developed they're own versions of MaxFileCount, its been out of date for years, as for one thing it can easily brick a phone, and it can take an hour or so to do its thing on others.
Its not a terribly hard app to write, shouldn't take more than an hour or two.

Thanks. But, being that I'm a "lowly tester" and not paid to create applications, I wouldn't do it on my end for this company. However, if there were a solution to MaxFileCnt 2.0 that would work better on the 3.x devices, I'd use that. Although, since I work for a corporation, it would have to be exclusively approved by QUALCOMM and/or NSTL.
Thanks, though.

Thanks. But, being that I'm a "lowly tester" and not paid to create applications, I wouldn't do it on my end for this company. However, if there were a solution to MaxFileCnt 2.0 that would work better on the 3.x devices, I'd use that. Although, since I work for a corporation, it would have to be exclusively approved by QUALCOMM and/or NSTL.
Thanks, though.

Sorry i wasn't aware.
Either way the information is still useful since you can take it to your studio people and ask them to build it.
Most publishers/studios are using their own version of maxfiles and have been for years, regardless of anything qualcomm says, as long as it passes the maxfiles tests its good to go, thats all they care about. As i said maxfiles is notorious for bricking phones, so its definitely an important part of your QA arsenal.

Sorry i wasn't aware.
Either way the information is still useful since you can take it to your studio people and ask them to build it.
Most publishers/studios are using their own version of maxfiles and have been for years, regardless of anything qualcomm says, as long as it passes the maxfiles tests its good to go, thats all they care about. As i said maxfiles is notorious for bricking phones, so its definitely an important part of your QA arsenal.

It's okay. I usually don't make it clear.
But, I would like a better maxfile solution. We're left with manually maxfiling the phones through the apploader at the moment until they're down to a reasonable limit to run MaxFile upon. I'll run it by our uppers and see what they can do about it. If not, I'll just have to develop something myself and propose it to our uppers.
Do you know if the source code for MaxFileCnt is available anywhere on the QUALCOMM site?

It's okay. I usually don't make it clear.
But, I would like a better maxfile solution. We're left with manually maxfiling the phones through the apploader at the moment until they're down to a reasonable limit to run MaxFile upon. I'll run it by our uppers and see what they can do about it. If not, I'll just have to develop something myself and propose it to our uppers.
Do you know if the source code for MaxFileCnt is available anywhere on the QUALCOMM site?

Uhh I'm fairly sure its included with the SDK, it certainly used to be available.
https://brewx.qualcomm.com/brew/sdk/authdownload.jsp?page=dx/commtoolsmisc
Perhaps this guy can help
http://www.youtube.com/watch?v=9N-yRo7bPLg

Uhh I'm fairly sure its included with the SDK, it certainly used to be available.
https://brewx.qualcomm.com/brew/sdk/authdownload.jsp?page=dx/commtoolsmisc
Perhaps this guy can help
http://www.youtube.com/watch?v=9N-yRo7bPLg

Thanks for linking me to my own video.
I am the BREW Ninja on YouTube.
Anyway, I discovered that if you change the file settings manually to 200,000 bytes on MaxFileCnt 2.0, it maxes out BREW 3.x phones much faster. However, the new Nokia flip still bricks. Guess that's just a phone we won't run MaxFile upon.
Thanks for the first link, however.

Thanks for linking me to my own video.
I am the BREW Ninja on YouTube.
Anyway, I discovered that if you change the file settings manually to 200,000 bytes on MaxFileCnt 2.0, it maxes out BREW 3.x phones much faster. However, the new Nokia flip still bricks. Guess that's just a phone we won't run MaxFile upon.
Thanks for the first link, however.

yeah i kinda figured that out ;)
if you use large block filesizes, it may not be able to test the mode where there aren't enough entries in the file table to create a file.

yeah i kinda figured that out ;)
if you use large block filesizes, it may not be able to test the mode where there aren't enough entries in the file table to create a file.

Updating MaxFileCnt is on our list of tasks, whenever time permits. :eek:

Updating MaxFileCnt is on our list of tasks, whenever time permits. :eek:

That's good. We'd need an update as phones get larger in Memory size.
And, we create larger block files, but then create smaller block files after the handset has seemingly filled up. It seems to work just fine for all of our testing needs.

That's good. We'd need an update as phones get larger in Memory size.
And, we create larger block files, but then create smaller block files after the handset has seemingly filled up. It seems to work just fine for all of our testing needs.

Well if you don't fill the maximum number of files it won't test all possible failures, as its possible to have free space but not be able to open a new file.

Well if you don't fill the maximum number of files it won't test all possible failures, as its possible to have free space but not be able to open a new file.

Similar to the MaxSpace test performed for the BREW 1.x devices? I guess we'll have to implement that as well. Thank you.

Similar to the MaxSpace test performed for the BREW 1.x devices? I guess we'll have to implement that as well. Thank you.