ok, not my day, apparently.

I used a new jad file when I fixed the previous problem (wrong CLDC version, as socabomb mentions), and the new file has different JAR file size than the published one... I'll try to get it right the first time around next time   

br
sambuca

Hi IF,

Please try again, it should work now.

Seems I didn't fix a problem with a typo in the JavaMO.jad file properly the last time. 

br,
sambuca

Viking,

I've seen reports around the Internet that this phone don't support bluetooth access from Java (jsr-82). Maybe thats the problem with hari's version. Don't know about my version though. I think I kept the application within the MIDP 2.0 spec, so you should make sure that the phone supports that. But it might just be that it's the bluetooth support that triggers the error, although it should have displayed the same message as hari's version.

best regards,
sambuca

1) we are talking about engineering a complex (and not necessarily guaranteed, esp at the OS level of the TCP connection) way of sustaining TCP connections when it isn't necessary. The whole point of (LMCE) devices is that they can stop and start, disconnect and reconnect as required. Modularity. Why build this complex extra functionality into DCERouter code, when it is a more elegant and clean/tidy just to close the device connections at suspend, and reconnect on resume. Both require code changes, but the latter is much more bullet proof and tidy.

2) the retain-connections option cannot survive a core reboot, or even a DCERouter reload, so this case would have to be handled anyway... and the simplest way to handle this would be to implement the former option above... which would solve the issue in the first place....

I guess that reconnecting the device would also restart the TCP connection from the core to the MD (because there is two, isn't there? One core->device and one device->Core ?)
If that is the case, I totally agree with this proposal, it keeps it simple 

As colin mentions, sending the device process a signal could probably do it. Don't know if a process can provide a suspend/resume hook to the kernel, or if there is a special resume signal, but the SIGHUP signal seems like a good candidate (wikipedia says something like: SIGHUP tells programs to reload configuration and reinitialize).

If the signal approach is used, it could be done from both the resume scripts and from the launch manager. As the LM already knows which devices are present (and possibly which ones need restarting, if some don't), it makes sense to me to let it handle this.
This depends on how the LM works, but at least it should be possible to do some ps | grep and bash scripting to get the process IDs to send signal to, using the device id as a start.

sambuca

I really found this "solution" to hackish to add the script, but then again, as it is now, the whole suspend issue is quite hackish.

I just added the script to the wiki. It will basically kill the devices, causing the spawner to restart them. But note that it has a restart count of 50, so it will only work 50 times. You also need to adjust it to match the devices running on your MD.

When I think about it, it should probably be possible to find the list of device ids running on this MD and do a restart on devices based on that.

Ok, just had to google this 
Found a interesting thread about TCP connections and suspend/resume : https://lists.linux-foundation.org/pipermail/linux-pm/2008-June/017742.html
According to this, connections can survive suspend, as long as there is no NAT and both sides of the connections silent. So, if we could tell the DCERouter to "be silent" for all connections to the suspended MD, we should have solved one part of the problem. This is actually consistent with my findings, it's only the connections to the MD devices that are affected, and not the ones from the MD to the core (as the MD is very silent when suspended).
 The other part of the problem is if the router recreates connections or otherwise do anything to them while the MD is suspended. Does it create new connections when reloaded?

br,
sambuca

I've used the method of restarting the devices on the MD at resume myself(this can be done with a script), but I see this as a hack, and no proper solution.

I agree that we should tell the core about our status, as it might need to know at some point. Perhaps it even should be some new status (MD_S2RAM/MD_S2DISK or whatever)?

Then there is of course the issue with maintaining or re-initiating the connections. Don't know the details of TCP programming, but it sure seems to just lock up the processes/devices in question after resume. Maybe a solution is to send a signal to every process to have it restart every connection to the core? At the other end, the core could restart the connections to the MD when it receives a MD_ON or MD_RESUMED status.

Just thinking out loud here...
Anyway, I suppose this kind of talk belongs in the dev forum :-)

br,
sambuca

Another update;

I've made another small improvement to the JavaMO. The image quality and signal strength screens are now working. The MO still starts with a default quality of 30, but I'm thinking about a better way. Maybe we should detect if the MO supports JPG and if not, we must use quality 100 (PNG), but if it does, we can start with the 70 setting, which seems to be default for all MOs.

On a side note, it is possible to compress PNGs also isn't it? If the BD Orbiter could send us PNG images instead, we could allow all phones to use the quality setting...

Key press handling has also been improved, it should now correctly detect and send keys in the "repeated key" list. For instance volume up and down keys in most media screens. It might need some sort of control on how many commands is sent, though, now it sends a bunch of commands, and from the logs on the MD I can see it still receiving them long after the key was released.
How does the PlutoMO fare in this regard?

Probably missed some things in this short summary. Anyone interested should check the svn 

The latest version is available at http://hob.dyndns.org/javamo/. I would appreciate some test reports :-)

best regards,
sambuca

I've also noticed this. I think the daemon is restarted at boot time, regardless of the setting.

Maybe a bug?

br,
sambuca

hari:Thanks for the offer, I'll keep that in mind. :-)

tschak909: It is quite possible that I might need some help when I really start to dig into the vmc. For the datagrid, it was quite easy to write the code using the original as a template. But I am sure that the vmc stuff is more complicated.
  I haven't made a plan for what to do next, but I think I still have some coding to do before starting to touch the vmc itself. Still need to make saving and loading of VMC files on the phone work, and there is also more BD commands to implement.

Anyway, I'll just have to see what the holidays bring this year, time to work on the MO or family stuff 

br,
sambuca

Hi Archer,

First you need to get lmce to see your files. In the web admin, open Files & Media -> Media Files Sync on the top menu. Now, on the left side you should see a folder structure. Here you should see your disk also.
I haven't used external or separate internal disks, so I don't know for sure, but I think lmce should detect them automatically, and present you with an option what to do with them.
You will find more information about this if you search the forum or the wiki.

When/if you see your drive in the left structure, navigate to the folder in question (all using the left structure). When you select a folder, you will see its contents on the right. In this right pane, you have a option to "Edit attributes for all files in this directory". Using this, you can edit attributes for all files in that directory. In 710 it is not possible to recursively set attributes in subdirectories, but I think this will be added in 810.

These subject has been discussed a few times already, so I am confident you will find better explanations elsewhere in the forum ;-)

br,
sambuca

Hi

Just a quick update. I've implemented a new datagrid/list for the JavaMO. This is the same datagrid that the original PlutoMO uses. Since I've never used the PlutoMO, I can't know for sure if is 100% identical, but I think it should be at least close. I trust you to give me feedback  Anyway, its much better than the previous device-specific list...

Additionally, I've started to add some support for the VMC stuff. No much yet, but more will come. Most obvious is the startup screen. It's what I think is the first screen on the PlutoMO (keep in mind, I've only studied the code, not used it). From here you can currently view the about, the log and exit the application. In the future you will see a list of the VMC items on the phone, and be able to delete them and start them.

After a few seconds the MO should receive a connection from the bluetooth dongle, and it will display the orbiter as before.

The new JavaMO.jar can be downloaded from the same location as before.

best regard,
sambuca

Hi chriss

I had to add

Code:

iocharset=utf8

to the options of my /home mount on the MD to get such files to play.

/etc/fstab should contain a line somewhat like this:

Code:

//192.168.0.50/home /home cifs iocharset=utf8,forcedirectio,credentials=/usr/pluto/var/sambaCredentials.secret 1 1

br,
sambuca

Hi

If you tell us the reason why you want such a setup, maybe we can tell you how to do what you want with the normal setup instead 

br,
sambuca

Hari,

good to know. I will try to implement the functionality of the Symbian orbiter as closely as possible in Java, so hopefully this will be possible.

br,
sambuca

Thom,

currently its not possible to do what you describe, the JavaMO only displays a list using the phone's default list implementation (usually this fills the whole screen, at least on the SE phones I've seen).

I am looking into the VMC stuff these days, so sooner or later it might be possible ;-) Haven't started coding anything yet, just trying to get a basic understanding of the components to decide how to structure the code.

sambuca