1 person found this helpful
I had the same problem. For me the problem was in HTML wrapper generated with FB3. I had changed minimum required player version to 10.1 in compiler options' wrapper section and the problem've gone. This is a 'reversed' case.
But in your case you are still using 10.1 codebase (according to function name that was not found). So if you've checked the FLASH_101 option back to false in your project you may also want to check if you have any external SWC libraries that may have the version set incorrectly. For example OSMF has an external linkage in our project.
And, of cause, the beloved browser cache... :O)
Thanks for the reply Mykola3296. I've doubled checked the html code, and it's set to 10.0, so I don't think that's the problem.
In terms of swc libraries, I think you're on to something. I went through sourceforge and downloaded a version of OSMF 1.0 (I believe it was tagged 1.0gm) and, after compiling with those classes, it seems to work. I've compiled an osmf-1.0.swc and all seems to be well.
I do wonder if the functionality of FLASH_101 changed at some point. I had assumed setting it to false would prevent any 10.1 specific features from being included in the swf. I'll have to look more into it.
lucastswick, I incline to cache problem here, nevertheless...
In our project (like in most OSMF projects with external plugins I beleive) there is a problem with cached swf files.
At least we are having them rather often.
The most problematic point is loading a module from within flash (say a plugin in factory). Browser oftenly does not do an update check having last-modified though. Introducing eTag helps here somehow. We are using Firefox for debug and test and came to completely disabling cache on developer machines + eTag on servers and that helps much!
Concerning your case, the function that does not pass a check is indeed located in a CONFIG::FLASH_10_1 block (lines 146-171 for revision 18655). So your assumption that it does not do what it is expected to do - I doubt it.
Anyway Multicasts were introduced in OSMF 1.5 - so there is no such code in 1.0 library.
Here is a consideration of a possible failure based on design you are loading OSMF externally or as an RSL in Flex:
1) You compile with 10.1 option on
2) Wrapper targets 10.1 as a minimum
3) Application loads and caches 10.1 OSMF.SWF
4) You compile back to 10.0 setting an option to false
5) Wrapper targets 10.0
6) Application starts and loads an external OSMF.SWF but uses a cached version (compiled to meet 10.1 features).
7) As a result version check does not pass.
The above scenario affected files with merged-into libraries to! That is why caching was disabled on developer PC :O)
What do you think?
Hmmm I see where you're going with that. Let me explain further our setup:
We're not actually using any plugins - osmf is embedded in one single swf. There are other swfs loaded as well, but they have no relation to osmf and are simply listening to/dispatching events (actually rather Penner's signals, our preferred method for event handling) to/from different interfaces. I am fairly certain there is only one instance of OSMF compiled into a single swf that is loaded a single time.
I have run into issues with browser caching the swfs, even after multiple clear caches, and I always trace an incrementing version number so I can tell for certain whether or not the correct file is being loaded. In this particular case, that was one of the first things I checked.
That said though, it does appear that I'm missing something.
It seemed to me that because I was getting errors regarding NetGroup when CONFIG::FLASH_10_1 was set to false, that there must have been some code in osmf about netgroup that wasn't blocked in the compile-time check, but, like you've mentioned, this isn't the case. I just checked build 19249, and indeed, everything concerning netgroup is blocked as expected.
I'm going to spend some time getting my head around this. Perhaps there is an error with my code, and OSMF is being compiled into one of the other swfs, and is fact cached. If this is the case, I'd owe you a beer.
Thanks again for all your help - I will keep you posted.