just remember.

if a file is 10 bytes,
if you read 10 bytes, return 10 bytes read, FMOD_OK.
if you read 11 bytes, return 10 bytes read, and FMOD_ERR_FILE_EOF.

so that check must be < not <=. Do not use FMOD_ERR_FILE_EOF to signify that you are at the end of the file, only -past- the end.
the opencallback takes back a filesize parameter so that lets fmod handle internally stopping it read too much if it needs to.

Well, as it turns out…

I didn’t set the file size! I’m going to test this out, but I’m fairly sure this would explain my problems, perhaps you should try the same.

HI!

I’ve the same problem, and I need a fast correction.
Please let me know if anyone knows how I can solve this problem.

The user above already solved his problem, you have probably filled out your callbacks incorrectly. Compare them to the fmod example.

But the another user does not and still waiting for an answer…

I had the same problem as detective67 has. This project started a year ago, and there was no problem until now. I didn’t modify anything and before I installed the new FMod 4.6.22 everything worked fine.
After brett’s mail I installed 4.6.22 again and I got FMOD_ERR_FILE_NOTFOUND again when I tried create a sound. The calling order was:
OpenFile:
*filesize <- 29.450.852 bytes

SeekFile( pos = 29.450.240 )

ReadFile( sizebytes = 2048 )
*bytesread <- 612
if ( *bytesread < sizebytes )
return FMOD_ERR_FILE_NOTFOUND;

CloseFile()

but the filecallbacks example didn’t close the file after that 612 bytes reading, it called the SeekFile with pos 0. I didn’t find any difference between our source and that example.

BUT!

After a while (I didn’t change the source!) it begins to work properly. I don’t understand, but once I started the program it worked. I don’t know how but it begins to work. (tried to undo the changes, but there wasn’t any changes)
I hope it will work in the future.
I would tell the answers if I know it…

provide a repro case and we can look at it.

Hi Brett and SR_hypnos,

I had some time to check my side of the problem, and it turned out that you have changed the prototype of the function setFileSystem() [it needs blockalign and not blocksize, I do not know whether it has a hit on its semantics] and I missed to refresh the header files in the project, so it was the reason why it did not work well.

So, this could be an another problem leads to troubles when using setFileSystem(). The moral of the story is: Hey kids, always merge the newest headers files when you are about to upgrade to a new fmod version

I am having a similar problem with my own setfilesystem. I am overriding all of the functions in order to custom load files, but when I call createSound the file open callback is triggered and returns successfully, seek/read do not get triggered, neither do attachFileSystem callbacks on seek/read, and it immediately goes to the close callback and return FMOD_ERR_FORMAT. The files are wave files that end in .wav, but the path I am passing in is not a full system path, which should not matter because my open file handler works just fine and returns the data it should. Am I missing something here?

I should note that I also used jaguar.wav from the examples, which plays file with filecallback example, and it still returns FMOD_ERR_FORMAT.

all we did was change the name, there is no difference in functionality to that parameter. We are trying to stop people thinking they can set that to large numbers. It should be aligned with the sector size of the machine, not some arbitrary number that hurts performance and streaming.

If you post your file callbacks here we can probably spot what your problem is. (remember use [code] [/code] tags)

I too am getting the same problem (only with loading the event system project), what previously worked (4.06.10), is now broken (on 4.06.22)..

Any ideas ?
=-
Steve.

Hi Brett and mac_bug,

I think you are going to laugh:

[code:5s0vfrla]
FMOD_RESULT F_CALLBACK myopen(const char *name, int unicode, unsigned int *filesize, void **handle, void **userdata)
{
if (name)
{
FILE *fp;

    fp = fopen(name, "rb");
    if (!fp)
    {
        return FMOD_ERR_FILE_NOTFOUND;
    }

    fseek(fp, 0, SEEK_END);
    *filesize = ftell(fp);
    fseek(fp, 0, SEEK_SET);

    *userdata = (void *)0x12345678;
    *handle = fp;
}

return FMOD_OK;

}

FMOD_RESULT F_CALLBACK myclose(void *handle, void *userdata)
{
if (!handle)
{
return FMOD_ERR_INVALID_PARAM;
}

fclose((FILE *)handle);

return FMOD_OK;

}

FMOD_RESULT F_CALLBACK myread(void *handle, void *buffer, unsigned int sizebytes, unsigned int *bytesread, void *userdata)
{
if (!handle)
{
return FMOD_ERR_INVALID_PARAM;
}

if (bytesread)
{
    *bytesread = (int)fread(buffer, 1, sizebytes, (FILE *)handle);

    if (*bytesread < sizebytes)
    {
        return FMOD_ERR_FILE_EOF;
    }
}

return FMOD_OK;

}

FMOD_RESULT F_CALLBACK myseek(void *handle, unsigned int pos, void *userdata)
{
if (!handle)
{
return FMOD_ERR_INVALID_PARAM;
}

fseek((FILE *)handle, pos, SEEK_SET);

return FMOD_OK;

}
[/code:5s0vfrla]

Of course, they are not what I actually use for the software (sorry, but the original callbacks have a lot of tricks and they would take too many lines to explain), but I tried these standard example callbacks in it too, and got the same results. So, I think it is enough to proove callbacks are not dirty in this case.

Is there any other function able to interfere with or act on setFileSystem()?

Thank you.

Provide a repro! So far everyone that says they have a problem haven’t shown us a thing. The callbacks work, it will be the contents of your callback that are the problem.

Well, I went in and replaced my callbacks with the filecallback example callbacks verbatim, and passed in an absolute path to the jaguar.wav file and it worked there. Of course in my actual callbacks I’m passing in my own aliases so instead of d:\jaguar.wav I’m doing something like sound:wav\jaguar.wav and other calls translates that internally to open, and it does open properly I can verify that. What baffles me is why my file close callback is triggered right after (which does get the same valid handle I returned in the open callback) and then createsound throws a ERR_FORMAT error – how exactly is FMOD determining which codec to decode the given file?

I’m wondering about this because why is it that my read and seek callbacks are not getting called at all, if in fact it’s supposed to read and seek the file headers to determine what file format it is? If FMOD uses file extension instead, would .wav not suffice? Suppose I must pass in "d:\jaguar.wav" instead of "sound:Wav\jaguar.wav" into createSound to make it work, I don’t see why FMOD would internally need the full path to the file or to open it without using my supplied callbacks. – on second thought, I am passing in whatever file I’m trying to read and hard coding it to load d:\jaguar.wav instead in myopen and it works, hmm

One more thing, with the supplied example callbacks, I am hooking up my read and seek filecallbacks to attachFileCallbacks just to see what happens, they do get triggered, but they only get passed in NULL handles (while the myread/myseek works perfectly fine)