Skip to main content

**** Resource menu.grin does not exist! ****

14 replies [Last post]
bddeveloper
Offline
Joined: 2008-01-14

Has anyone seen this error when running the hd cookbook menu (I opened the 00004.jar file and the file menu.grin is there:

[BDJAppProxy.stateTransition()] state change succeeded : BDJAppProxy (1450744508, 16385, com.hdcookbook.bookmenu.monitor.MonitorXlet), 2 -> 0
Tried /DOCR/signed/00004/menu.grin

**** Resource menu.grin does not exist! ****

java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Unknown Source)
at com.hdcookbook.grin.util.Debug.assertFail(Unknown Source)
at com.hdcookbook.grin.util.Debug.assertFail(Unknown Source)
at com.hdcookbook.grin.util.AssetFinder.getURL(Unknown Source)
at com.hdcookbook.bookmenu.menu.MenuDirector.createShow(Unknown Source)
at com.hdcookbook.bookmenu.menu.MenuXlet.animationInitialize(Unknown Source)
at com.hdcookbook.grin.animator.AnimationEngine.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
at java.lang.Thread.startup(Unknown Source)

*** Assertion failure: ***

******************************
* ABORTING DISC PLAY *
******************************

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chihiro_saito
Offline
Joined: 2006-11-08

Thanks Lorenzo, I'm glad that I asked. So this is a choice, not a need.

I've been working under the same assumption as Bill... that compilers evolve and bugs get fixed, so it is better to use a newer version. I didn't realize that docs related to CDC 1.1 recommend jdk 1.4 javac, but they could be doing so just to play safe over efficiency.

On a side note, I remember that the cvm and cdc 1.1 related impl from Sun itself had a build system that doesn't compile with jdk 1.5 or newer for a long time. It was mainly due to a lack of requests to allow newer versions, and nothing philosophical.

Chihiro

chihiro_saito
Offline
Joined: 2006-11-08

Hi,

You're probably hitting a player implementation bug. The code below in MenuXlet.java has been discovering different bugs in different players.

============
assetsJar = new ServiceDomain();
try {
BDLocator loc = new BDLocator("bd://JAR:00004");
assetsJar.attach(loc);
============

Try signing 00004.jar. If that doesn't work, then I can only suggest to include the content of 00004.jar to 00002.jar and comment out the mounting code. Both are workarounds.

Hope it helps,
Chihiro

bddeveloper
Offline
Joined: 2008-01-14

Hello Chihiro,

The player bug is happening on the latest softplayers from Corel and Cyberlink. Both report the exact same error.

I changed the ant file build_bdjo_security.xml to look like this:







However this did not do the trick. Maybe there is another place I need to update?

Also if this is a workaround should the player companies be contacted or is this something that should be fixed in the source code for the cookbook?

Thank you,

Scott

chihiro_saito
Offline
Joined: 2006-11-08

Hi Scott,

With your change, you're signing 00004.jar. If that doesn't help, you can also try to include all assets to 00002.jar. Here's roughly how.

In MenuXlet.java starting line 202:

============
/** workaround: commenting out
assetsJar = new ServiceDomain();
try {
BDLocator loc = new BDLocator("bd://JAR:00004");
assetsJar.attach(loc);
} catch (Exception ex) {
if (Debug.LEVEL > 0) {
// If this happens, it's a bug.
ex.printStackTrace();
}
}
**/
//File[] path = { assetsJar.getMountPoint() } ; // current code
File path= { new File("."); } // new code, workaround
============
.... and in build_hdcookbook_xlet.xml, change the "build-menu-xlet" target's jar command to include assets for 00004.jar into 00002.jar.

We don't want to include workarounds to our sample code by default. We have an internal bug database for players and report them back to the manufacturers whenever we can. There are some comments on it on trunk/player_workarounds.txt.

As the specific software players you're mentioning - I received a drop from Corel last week that includes a fix to this problem. Cyberlink exposed a similar failure last year and they were quick to fix it then, but I haven't seen such failure for a while, including w/ the latest player version we have, so it is quite possible that you're hitting a bug that we haven't seen on that.

If you have a channel to report this back to Cyberlink, I'd be happy to work with you, please send me an email (chihiro_saito at dev java net).

Thanks,
Chihiro

bddeveloper
Offline
Joined: 2008-01-14

Hello Chihiro,

I will ensure I have the latest Power DVD and WinDVD (maybe the auto upgrade didn't fully upgrade it to the latest). Like you I am not a fan of workarounds, so I think I'll roll back my power DVD and continue to work.

Thanks,

Scott

chihiro_saito
Offline
Joined: 2006-11-08

Hi Scott,

> so I think I'll roll back my power DVD and continue to work.

OK, that's an option. Thanks for letting us know about this problem.

Chihiro

Lorenzo Pallara

hi all!

we are trying to run today svn checkout of grin and we are going thru the same path.

we believe that this error "Resource menu.grin does not exist!" is not only related to a signature/security problem.

it's about a missing file, the "binary compiled" version of menu.txt ; a
description of the show that is indeed present in the root directory of
the 00004.jar and should be compiled using the grin binaryconverter but we are getting this errors back:

$HOME/jdk1.6.0_03/bin/java com.hdcookbook.grin.binaryconverter.Main -debug -asset_dir 00004jar menu.txt

*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa
*** Helper didn't find font Lisa

Unrecognized feature "modifier" on line 1440

Error trying to parse menu.txt
java.io.IOException: Unrecognized feature "modifier" on line 1440
at com.hdcookbook.grin.io.text.Lexer.reportError(Lexer.java:124)
at
com.hdcookbook.grin.io.text.ShowParser.parseFeature(ShowParser.java:400)
at com.hdcookbook.grin.io.text.ShowParser.parse(ShowParser.java:252)
at
com.hdcookbook.grin.io.text.ShowParser.parseShow(ShowParser.java:2082)
at com.hdcookbook.grin.binaryconverter.Main.convert(Main.java:228)
at com.hdcookbook.grin.binaryconverter.Main.main(Main.java:184)

here we find two problems:

1. the Lisa font (maybe just a warning?) it's a mismatch between a TTF
in the filesystem and a description about another kind of font ( otf kind?)

cat dvb.fontindex

"http://www.dvb.org/mhp/dtd/fontdirectory-1-0.dtd">


Lisa
OTF
00000.otf

2. some keywords unrecognized in the menu.txt like modifier and
book:playvideo

we guess svn has old data compared to source code... we'll appreciate a lot if anyone can shed some light on this stuff!

bye

andrea venturi and lorenzo pallara

bd-j-dev@mobileandembedded.org wrote:
> Hi Scott,
>
>
>> so I think I'll roll back my power DVD and continue to work.
>>
>
> OK, that's an option. Thanks for letting us know about this problem.
>
> Chihiro
> [Message sent by forum member 'chihiro_saito' (chihiro_saito)]
>
> http://forums.java.net/jive/thread.jspa?messageID=262262
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
> For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

chihiro_saito
Offline
Joined: 2006-11-08

Hi Lorenzo, Andrea,

> it's about a missing file, the "binary compiled" version of menu.txt ; a
description of the show that is indeed present in the root directory of
the 00004.jar and should be compiled using the grin binaryconverter

If you do a checkout from our repository and invoke ant on the toplevel, then "menu.grin" should end up in the root of the 00004.jar. Scott reported that he has this file. I guess you're building our code in some other way?

As for the errors, the binary converter needs to be invoked with a search path set so that Lisa font can be found, and with a proper ExtensionParser classname as an argument so that custom extensions (in this case, "Book:PlayVideo" custom command) can be parsed. You can look at grin/scripts/ant/build_hdcookbook_xlets.xml, "generate-binary-script" target for the binary converter arguments we have for menu.txt conversion.

Chihiro

PS. Your posting on "a reference video about t-islessia" have been forwarded multiple times within Sun; it's neat!

Lorenzo Pallara

Hi Chihiro!

bd-j-dev@mobileandembedded.org wrote:
> Hi Lorenzo, Andrea,
>
>
>> it's about a missing file, the "binary compiled" version of menu.txt ; a
>>
> description of the show that is indeed present in the root directory of
> the 00004.jar and should be compiled using the grin binaryconverter
>
> If you do a checkout from our repository and invoke ant on the toplevel, then "menu.grin" should end up in the root of the 00004.jar. Scott reported that he has this file. I guess you're building our code in some other way?
>
>
Good guess ;-) ! We are using a different build starting from svn
sources, sorry we should state that at the begin! We use jdk1.4.2 for
xlets because we use target 1.1 and source 1.2 but svn build is using
the same jdk for all the build, so probably we missed some points while
changing, we started from a fresh svn and using ant at top and it does
build menu.grin and the disc root as expected

> As for the errors, the binary converter needs to be invoked with a search path set so that Lisa font can be found, and with a proper ExtensionParser classname as an
also ant build warns but doesn't seem a problem in the end:

init-grinview:

compile-grinview:

generate-binary-script:
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa

> argument so that custom extensions (in this case, "Book:PlayVideo" custom command) can be parsed. You can look at grin/scripts/ant/build_hdcookbook_xlets.xml, "generate-binary-script" target for the binary converter arguments we have for menu.txt conversion.
>
I will check out what's wrong about the custom command, thanks you for the quick answer and the useful hints.

bests,
Lorenzo

> Chihiro
>
> PS. Your posting on "a reference video about t-islessia" have been forwarded multiple times within Sun; it's neat!
>
:-)

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

chihiro_saito
Offline
Joined: 2006-11-08

Hi Lorenzo,

> We use jdk1.4.2 for xlets because we use target 1.1 and source 1.2 but svn build is using
the same jdk for all the build,

Oh, OK, interesting. It seems to me that it might be pretty easy to change this in our build system though, by adding a "compiler" option to the preset javac tasks defined at grin/scripts/ant/preset_defs.xml, for example. Will that address your need?

> generate-binary-script:
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa
[jdktools.java] *** Helper didn't find font Lisa

You're right... this actually seems to be an cleanup item needed, FontHelper shouldn't be invoked during grin compilation time. Will fix shortly.

Thanks,
Chihiro

Lorenzo Pallara

Hi Chihiro,

>> We use jdk1.4.2 for xlets because we use target 1.1 and source 1.2
>
> Oh, OK, interesting. It seems to me that it might be pretty easy to change this in our build system though, by adding a "compiler" option to the preset javac tasks defined at grin/scripts/ant/preset_defs.xml, for example. Will that address your need?
>
>
I will check that!

thanks,
Lorenzo

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

chihiro_saito
Offline
Joined: 2006-11-08

Hi Lorenzo,

>> We use jdk1.4.2 for xlets because we use target 1.1 and source 1.2

When you have time, could you elaborate this a bit more? I was thinking about this over the weekend and started wondering why one will need a different jdk for compiling xlets.

I originally thought that maybe newer jdk javac removed "target 1.1 source 1.2" option, and that is why you want to use jdk 1.4, but then jdk 1.6 javac does seem to support this option still. I must be missing something.

Thanks,
Chihiro

Lorenzo Pallara

Hi Chihiro!

>>> We use jdk1.4.2 for xlets because we use target 1.1 and source 1.2
>>>
>
> When you have time, could you elaborate this a bit more? I was thinking about this over the weekend and started wondering why one will need a different jdk for compiling xlets.
>
> I originally thought that maybe newer jdk javac removed "target 1.1 source 1.2" option, and that is why you want to use jdk 1.4, but then jdk 1.6 javac does seem to support this option still. I must be missing something.
>
> Thanks,
> Chihiro
> [Message sent by forum member 'chihiro_saito' (chihiro_saito)]
>
>
At the begin I started using javac 1.4.2 for xlets as a suggestion from
papers like the CDC build guide and others references, they were
reporting CDC is based on 1.4.2 so the "suggested" compiler is javac
from jdk 1.4.2: outdated docs/articles or is there a reason?

I tested javac from jdk 1.6 with -target 1.1 and -source 1.2 and I found
a few classes were different in a few bytes and usually it was happening
to the most complex ones, so a difference existed (exists) even if I
wasn't able to know what is it about.

So what should I (we?) do: take the latest and greatest or stay with the
old (stable?) one?

My final decision to stick with javac from jdk 1.4.2 and to don't go
further into the subject comes from reports like this one about
cross-compiling: (http://blogs.sun.com/darcy/ )

>
> Additionally, even when the bootclasspath and -source/-target are all
> set appropriately for cross-compilation, compiler-internal contracts,
> such as how anonymous inner classes are compiled, may differ between,
> say, javac in JDK 1.4.2 and javac in JDK 6 running with the -target 1.4
> option.
>
> The most reliably way to produce class files that will work on a
> particular JDK and later is to compile the source files using the oldest
> JDK of interest.

bests,
Lorenzo

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

Bill Foote

Lorenzo Pallara wrote:

> So what should I (we?) do: take the latest and greatest or stay with the
> old (stable?) one?
>
> My final decision to stick with javac from jdk 1.4.2 and to don't go
> further into the subject comes from reports like this one about
> cross-compiling: (http://blogs.sun.com/darcy/ )

Hi Lorenzo,

It's OK to use a newer javac - that's what we do.

Reading that blog entry (entry for Feb. 25 2008 entitled
"How to cross-compile for older platform versions"), Joseph
says the right thing: It's fine to use a newer javac, provided
that you're sure to set the bootclasspath to the platform you're
compiling for. With BD-J, you need to do that anyway, to get the
PBP/CDC platform (instead of the SE platform), and to pick up the
GEM/BD-J classes.

Using "-target" to compile to an earlier classfile version is
thoroughly tested. I do believe your report of getting a different
binary result, but that's probably just because the JDK 1.6 compiler
is better.

Cheers,

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net