(2013-08-03, 02:42)navigates Wrote: (2013-08-02, 23:36)CaptainTivo Wrote: (2013-08-02, 23:26)navigates Wrote: Not True. With my configuration, the remote does hibernate. Without hibernation battery lasts 3 days. with hibernation it goes on for 45 days. I did notice if I boot directly to xbmc as shell, the hibernate feature does not work and the battery dies in 3 days. I went through two rounds of batteries until i switched back to desktop mode.
Not sure what you mean by "boot directly to xbmc as shell"? Can you please explain? Can you also give your configuration: what BT dongle do you have, what version of OS, etc?
I am running Windows 7 with updates with an ASUS USB BT211 dongle. I boot windows. I pair the remote control, I then run PS3Blumote. I then run XBMC. I have enabled the auto hibernation feature with a one minute timeout. I verify in the debug log that hibernation is attempted. I correlate the time that Blumote indicates that it has hibernated the remote with the current draw at that time and there is NO reduction or fluctuation of the current. As I said, I have tried PS3RemoteSleep and it will hibernate the remote. Since miljbee says he used this same code in his version of PS3Blumote (2.04), it should function just like PS3RemoteSleep, but it does not. I assure you that my configuration does not work. The question is: why not?
By direct to shell I mean that the windows explorer does not boot and I boot to xbmc as a shell. You have to make a bootup file in a config folder to load all the startup items before xbmc. However that disables the hibernate feature of the ps3blumote.
Question. When the ps3blumote application goes in hibernate, do you see the blue play sign go light blue? If not then I don't think its hibernating. I can check my log file to validate it as well.
Hi. I'm on Windows 7 with the Intel NUC i5 version. I have made the similar configurations fro others on the i3 version of the NUC as well. I use the intel internal wifi and bluetooth card made by Intel. I had tried the bluetooth dongle with the Lenovo Q190 and that was a nightmare in getting the remote to sync and stay synced. With the intel nuc the resync is instant. I can validate the battery draw for you if you'd like. I just don't know how to. Can you specify so I can do it as well?
I just purchased a Red LED Panel Meter Mini Lithium Battery Digital Voltmeter DC 3.3V - 17V S9
Hope to get conclusive answers once i receive it. Since the meter is coming from China to LA I guess that will take time.
http://cgi.ebay.com/ws/eBayISAPI.dll?Vie...0629381271
Hmm. I dont see how running XBMC rather than the windows shell would affect hibernation since it is Blumote that is running the code to cause the hibernation, but I'll take your word that it does not work.
Anyway, I thought about it some more and I found the answer. First, started with a totally different computer, which I am not using for a home theater PC. It is also running Windows 7. I first simply inserted the Asus BT adapter. Windows complained that it could not find a driver. I then downloaded the driver installation (100 Mb!) from Asus web site and installed it. Then inserted the BT adapter and it installed fine. I take this to mean that it is not using the Windows BT drivers. I then downloaded Blumote 2.04 via the new link in the first post. Before, I had downloaded it from the link in miljbee's post.
Running Blumote, it complains that there is no settings file and it creates a new one. Then I set auto hibernate to 1 minute. And lo and behold: It did hibernate the remote. Hmmm. I then took the remote back to my HTPC, where it did not work before. I downloaded and installed the "new" 2.04. This did NOT fix it (no hibernation). Hmmm. I then remembered that the new installation on the other machine had created a new settings file. Maybe that was the cause. I opened the settings file in a text editor. It seems to be and XML file. But here is the key, there is a tag which identifies the BT address of the adapter:
<btaddress>34:c7:31:01:e2:52</btaddress>
I then opened the BT device in the Devices and Printers app and looked that the properties of the adapter device. The BT unique ID was not the same as the one in the settings.ini file! Then I remembered. I had downloaded the ini file from this thread
http://forum.xbmc.org/showthread.php?tid...pid1451571 to get the key mappings. The problem is, this ini file already had a BT address in it. So I assume PS3Blumote is trying to hibernate the wrong BT device. I replaced the btaddress tag with the BT ID for my device and voila, it worked.
So the lesson is: if you replace the settings.ini file, make sure you set the btaddress to the one for your own BT device.
Now, the only problem I have is that same one that many other people are having. Most of the time, after the remote is hibernated and you press a button, it comes out of hibernation immediately and the button press is captured by PS3Blumote. However, sometimes, the remote will go into a mode in which it starts blinking the PS3 LED-lit button and it will not wake from hibernation for up to 20 seconds. The problem is that if you don't get an immediate response, the natural action is to press more buttons. If you press more that one key, these seem to be queued and, after the exit from hibernation, are sent to PS3Blumote all at once. Does anyone know why this behavior happens? I have tried waiting various time periods after hibernation to press a button but I dont see an obvious correlation between the wait time and whether it will go into the led-blink mode. The led-blinking reminds me of when you put the remote into discover mode by pressing Start and Enter at the same time. Is is possible that it is somehow going into discover mode?