Hosed part of dynamic data

So .. you can put 1+1 together here with my previous post about starting to add Dynamic Data writing support into jEmplode and figure out what MAY have happened

So I finally got the code so that I think it is doing the correct thing to write dynamic data. However, during one of my fumbles, I wrote some random data in the DynamicData of an FID. Now it appears that neither my jEmplode NOR Emplode (beta11) can write changes back to the DynamicData. Have you guys seen a case where beta11 is not able to write data back? Also, is there a way to totally zero the dynamic data assuming I sprayed random bits across a chunk of it?

Mike

Have a search through the BBS - I *think* there was something about clearing the dynamic data from the empeg guys a while back ...

Now it appears that neither my jEmplode NOR Emplode (beta11) can write changes back to the DynamicData. Have you guys seen a case where beta11 is not able to write data back?

No, you shouldn't be able to hose it so badly that Emplode can't write to it.

Also, is there a way to totally zero the dynamic data assuming I sprayed random bits across a chunk of it?

The dynamic data for fids lives from offset 2Mbytes onwards in /dev/hda3, up to the end. Before the 2Mbyte mark are the bookmarks, the EQ settings, and the tuner presets.

Peter

Hi.

A thought just crossed my mind when I read that:

Would it be possible for you (the guys at empeg) to specify a small region (say 4k or something) on /dev/hda3 that could be used by third party programmers? Like for bass/treble settings, left/right delay, button brightness specs etc.
Just those relatively small, seldomly chaning settings that are currently stored in the extremely tight flash savearea.
I guess far less than the mentioned 4k would be sufficient, but 4k is probably the smallest amount that could be allocated exclusively to 3rd party, without possible read/write conflicts between the player software and third party tools.

cu,
sven

cu,
sven

Well, actually, there's an 8KB flash area that's currently unused..

I've definitely managed to do something -- It's very odd, the player can still toggle the marked setting, but Emplode clearly cannot set or unset the value. Before I zero that block, is there anything you guys might like to see, or should we just assume this is a strange fluke and move on with our lives ?

Mike

It's very odd, the player can still toggle the marked setting, but Emplode clearly cannot set or unset the value.

Can Emplode see the value set by the player?

Oh, hang on, I can't set or clear markedness with Emplode in the current build either

I think this one's not your fault...

Peter

Since writing dynamic data isn't in Emptool, if you find that fixing this bug required a change in the way you write the data, can you drop me a line and let me know what I need to change in jEmplode?

Thanks a lot
Mike

Since writing dynamic data isn't in Emptool, if you find that fixing this bug required a change in the way you write the data, can you drop me a line and let me know what I need to change in jEmplode?

Writing the *F file will remain the right way to do it. If it turns out not to work, that's a player bug.

Peter

It's curious that both Emplode and jEmplode fail in the same way ... sounds suspiciously like a player bug? Still possible that jEmplode could just be implemented wrong, though