Messages

391

Users / Re: Suspend to RAM

« on: January 08, 2009, 11:44:24 pm »

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

392

Users / Re: Suspend to RAM

« on: January 08, 2009, 10:08:00 am »

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

393

Users / Re: Suspend to RAM

« on: January 07, 2009, 11:11:21 pm »

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

394

Developers / Re: Java/ J2ME mobile orbiter

« on: January 05, 2009, 10:08:04 pm »

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

395

Users / Re: Update Media Daemon: eats cpu despite being disabled

« on: December 26, 2008, 07:21:05 pm »

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

Maybe a bug?

br,
sambuca

396

Developers / Re: Java/ J2ME mobile orbiter

« on: December 18, 2008, 10:26:56 am »

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

397

Users / Re: update attributes

« on: December 18, 2008, 09:31:52 am »

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

398

Developers / Re: Java/ J2ME mobile orbiter

« on: December 17, 2008, 11:37:20 pm »

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

399

Users / Re: Playing files with "special chars" (äöü) on MDs fails

« on: December 17, 2008, 09:29:55 am »

Hi chriss

I had to add

Code: [Select]

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: [Select]

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

400

Users / Re: Multiple hybrid machines

« on: December 16, 2008, 09:44:30 am »

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

401

Developers / Re: Java/ J2ME mobile orbiter

« on: December 09, 2008, 10:57:40 am »

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

402

Developers / Re: Java/ J2ME mobile orbiter

« on: December 08, 2008, 11:37:53 pm »

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

403

Developers / Re: Java/ J2ME mobile orbiter

« on: December 08, 2008, 10:00:52 pm »

Hi Marco,

thanks for the feedback.

The shifted media menu is strange. I think this menu is rendered by the bluetooth_dongle orbiter, so I don't think it has anything to do with the JavaMO itself.

I added device independent key mappings in the second version, so maybe I introduced a bug, although I cannot see any difference to the Nokia key mappings. I'll look into it some more. Maybe you can run the keycodes app that hari posted a while back and report your key codes?

Did the back button take you back one level from the media list before? On hari's original JavaMO or on my first version?
The media list needs more than 250 items to display as a filtered list.

The red button should not exit the app. (if this is not the phones default behaviour?) Maybe you can report the keycode for this key from the keycodes app. also, so that I can add it?

br,
sambuca

404

Users / Re: HD tv with internal decoder?

« on: December 07, 2008, 03:37:15 pm »

Hi vorik,

Basically any DVB card supported by linux will work with LMCE, although not necessarily plug-and-play. For smartcard/encrypted channels, you should get a card that supports a CAM/CI for you cable provider.

I suggest checking out the lmce wiki, search this forum for post regarding DVB and cable. The linuxtv.org website is also worth a visit.

br,
sambuca

405

Developers / Re: Java/ J2ME mobile orbiter

« on: December 07, 2008, 12:55:01 pm »

Hi again,

I've made some more improvements to the JavaMO. Since last time, I've added basic phone detection, allowing for easy definition of different key mappings. Currently, I've added key mappings for Nokia (the same as was in the original MO), and for SonyEricsson. The SE mappings are made for the W580i phone, I'll try to add for the K800i soon also.
 I've used one class per phone brand (for now). It may be a bit of overkill, but I often find that it is best to separate things at the beginning, because it is easier to expand on it later without creating a mess

I also found out that the W580i (and quite a few other SE phones according to SE support) does not allow a list to have more than 255 items in them. This explains my problem with all blank entries(besides the last one). To work around this, I implemented a filtered list. The new list checks the number of items, and if it is above a particular size, it displays a list of the first characters in the list. When you select one character, you will see the list of the items starting with that character.
 I think this list also improves navigability of media on the MO. I'd like to get some feedback on this list, both from a usability perspective but also regarding stability (better/worse/same as the plain list).

The list should also handle UTF-8 character now.

New version uploaded to http://hob.dyndns.org/javamo/. Enjoy

br,
sambuca