[RELEASE - BETA] service.datasync

(2012-04-30 00:46)RockDawg Wrote:  The newer version stops the error message, but now the log says:

Code:

18:32:29 T:3018127104  NOTICE: Samba is idle. Closing the remaining connections
18:35:49 T:2995223360  NOTICE: Data Sync Service:: Starting Sync
18:35:49 T:2995223360  NOTICE: Data Sync Service:: Cannot Connect to Server, please check IP Address and Port Number
18:35:49 T:2995223360  NOTICE: Data Sync Service:: No Files to Sync
18:35:49 T:2995223360  NOTICE: Data Sync Service:: Finished Sync
18:35:49 T:2995223360  NOTICE: Data Sync Service:: Next Run is Sun, 29 Apr 2012 19:35:00

I double-checked the config and the IP address is the correct address for my server PC. I have the port number the same as it's set in settings>network>services>allow control of XBMC via HTTP>port on the server PC. That's the correct port number, right?

I still can't figure this out. My config info all seems right, but the client just will not connect to the server and I have turned off Windows Firewall just to check, but it still won't connect. Does anyone have any suggestions to get this working?

(2012-04-30 16:52)robweber Wrote:  Not sure of the inner workings here, but reducing the amount of a time a thread is sleeping will allow it to check for the xbmc.abortRequested command a lot faster. Many services have the thread sleep time set to 10 seconds or less to avoid hangs when trying to exit. it is especially troublesome when you want to close XBMC and then try to open it but the process hasn't exited yet.

Rob
I had set the sleep time to 5 minutes after every iteration of the WHILE loop. My concern was that the loop would consume system resources. Again, I'm still trying to lesrn this stuff, so if 10 secs is more appropriate, I will make the change.
As you correctly point out, it will require a little more logic on the server loop, but that should be managable. I'm thinking of recording the datetime that the files were created in a variable and checking the current datatime against that before recreating the files.
Would you hard-code that checkpoint to a set number of mins, (say 5) or offer it to the user as a setting?

Thanks again for all the input.

Declan

RockDawg
There could be a couple of issues here.

First off, lets make sure the webserver is running on the server instance.
On the CLIENT, open a browser and go to http://serverIP:serverPort/ eg http://192.168.0.50:8080/
If that doesn't open the XBMC web interface, then the issue is that the client cannot see the server's webserver.

If the XBMC web intrerface does open, we need to next check that the add-on is working correctly on the server.
On the server, navigate to your userdata directory for XBMC.
Within that directory you should be able to navigate to /userdata/addon_data/service.datasync/
Within that directory you should see 7 text files prefixed with ds_ (eg ds_rss.txt)
If those files are not there, the issue is with the add-on running on the server, please restart the server and post a debug log.

If neither of those are the issue
Go back to your browser on the client and now add the following to the URL
http://serverIP:serverPort/vfs/special://masterprofile/addon_data/service.datasync/ds_rss.txt

that should open a page something like this.


let me know what happen and we can take it from there.



Declan

RockDawg

Random thought.. Do you have a password set on the Network settings on the server? If so, that may be the issue. Can you try clearing the password just to terst it? I will also check this tonight, can't check will at work...

does this work with the client being an atv2 with smb shares for the sources??

(2012-05-01 16:56)DecK Wrote:  

(2012-04-30 16:52)robweber Wrote:  Not sure of the inner workings here, but reducing the amount of a time a thread is sleeping will allow it to check for the xbmc.abortRequested command a lot faster. Many services have the thread sleep time set to 10 seconds or less to avoid hangs when trying to exit. it is especially troublesome when you want to close XBMC and then try to open it but the process hasn't exited yet.

Rob
I had set the sleep time to 5 minutes after every iteration of the WHILE loop. My concern was that the loop would consume system resources. Again, I'm still trying to lesrn this stuff, so if 10 secs is more appropriate, I will make the change.
As you correctly point out, it will require a little more logic on the server loop, but that should be managable. I'm thinking of recording the datetime that the files were created in a variable and checking the current datatime against that before recreating the files.
Would you hard-code that checkpoint to a set number of mins, (say 5) or offer it to the user as a setting?

Thanks again for all the input.

Declan

I use a user setting to run an update every X hours. Hopefully seeing the source will help: https://github.com/bstrdsmkr/1Channel/bl...service.py

If you minimize the amount of work it takes to "determine if I should run," Then you can set the sleep pretty low (I've used 250 milliseconds) without any trouble. I could turn it way up, but the performance gain is undetectable. Not even 1% cpu usage reduction on an iphone's a4 processor.

(2012-05-01 18:49)rflores2323 Wrote:  does this work with the client being an atv2 with smb shares for the sources??

It should.

---

(2012-05-01 20:28)Bstrdsmkr Wrote:  If you minimize the amount of work it takes to "determine if I should run," Then you can set the sleep pretty low (I've used 250 milliseconds) without any trouble. I could turn it way up, but the performance gain is undetectable. Not even 1% cpu usage reduction on an iphone's a4 processor.

OK, I will try it with a low sleep number (no, I'm not hawking beds....)

Cheers for the reference materials on the user settings for the server riming.

I've updated the add-on, reducing the sleep time to 5 seconds. Also added a user setting for 'Server Refresh Time (mins)' which drives how often the log files are generated on the server side. All changes are in GIT.

(2012-05-01 17:42)DecK Wrote:  RockDawg

Random thought.. Do you have a password set on the Network settings on the server? If so, that may be the issue. Can you try clearing the password just to terst it? I will also check this tonight, can't check will at work...

It turns out that the password was the problem. When I tried:


I received a prompt for my username and password. Once provided, I saw the results you said to expect. I removed the password and username from the server and now it works.

OK, good news.
I will log an issue on this. It should respect passwords if the user wishes to implement one. But for now, you will have to leave it off.