xmdsProcessing can be left set to true

It is likely that this is caused by an exception in the file collection routine that causes the routine to stop, but doesn't cause the xmdsprocessing flag to be reset.

I can see a few places where there is a potential for this flag to be left in the "true" state. However I can't think of a sensible way to improve it, without pulling the entire thing apart and recoding with a better design (it should really work more like the Python client does, with independent, threaded calls to the various web services).

This recode should be a longer term goal (with many other things between then and now).

As as temporary workaround I could build in a flag that checks the last time we successfully connected to XMDS and processed a response. If this time was longer than a user configurable number of seconds ago (default of... say 300) then I could assume an uncaught error situation and reset the processing flag at the next collection interval.

Thoughts on this "workaround"?

So, in 300 secs timeout approximately 2kb/s broadband should be fine to download 500kb chunk and send next request, right?

Sounds reasonable for me. Target (no need to check every client every day) archieved :) Any chance for make 100% sure that no other communication tooks place in that situation by killing any remaining network operations etc?

Personally I think it makes more sense to implement it as a multiple of the collection interval.

So for example lets say we set a default of 3x (there would be no config gui option to change this, but it could be possible to change it directly in the player config file).

If the collection interval is set to 300 seconds, then 1500 seconds would have to elapse without a sucessful webservice call for this timeout to come in to play.

3x may not be the correct multiplier, but it would save most people even having to know about this option and would also be a sensible default for most people.

Alex

Lol. My maths suck. It would of course be 900 seconds that would have to pass.

A

Agree, better idea than fixed value.

I don't see the link with the collection interval, a single collection might
have 50 requests and each one could exception?

I can see we wouldn't want to expose the timeout through the user options
though.

Seems the workaround is good in principle though.

On 18 Feb 2010 23:05, "Bartek" <email address hidden> wrote:

Agree, better idea than fixed value.

--
xmdsProcessing can be left set to true
https://bugs.launchpad.net/bugs/522861

You received this bug notification because you are a member of Xibo
Maintainters, which is the regis...
Status in Xibo Open Source Digital Signage: In Progress

Bug description:
Hello.

Today i've got similar problem as low quality 3g, on vpn connected over
st...

@Bartek - Implemented in the linked branch if you want to make some binaries and try it...

Just installed on some client. Thanks :)

Hi.

There is a log from last source, hangup is detected correctly, but transmission is not restored, in effect of error:

Error: <message>There was an error during asynchronous processing. Unique state object is required for multiple asynchronous simultaneous operations to be outstanding.</message><method>Schedule - RequiredFilesCompleted</method>

Client was down for 3hours on good 2mbit dsl connection.

http://czajkowski.net/~czajka/xibo/XiboDebug0103.txt.gz

Seems like the previous request was still active. I'll try calling a cancel
after detecting the time out.

Any chances for some theoretical fix for this in next few days ? :)
It would be nice to test it simultaneous with silent crash catch. If not i'll start to testing separately.

Anyway, as always: thanks for your hard work!

nothing yet im afraid... would I be right in saying that ignoring the xmdsProcessing flag has actually made it worse for you?

Rather simply no change :)
Later hangup was simply ignored so no restart of transmission occured.
Now hangup is detected, but there is no effect, becouse enviroment consider previous request as still active, so ignoring tries to reinit communication.

Hi,

I've got two next clients with broken xmds communication, same error in log (last code revision, last .net, etc):
http://czajkowski.net/~czajka/xibo/XiboDebug2203-01.log
http://czajkowski.net/~czajka/xibo/XiboDebug2203-02.log

Any chance for fixing it by forcing some xmds session kill when timeout reached, or it's impossible becouse of client code contruction? :)

Cheers.

I'll look at your logs when I get a moment.. I am away of the next few days
so there may be a delay before I can get to it.

I am pretty sure I have done everything possible with that code to try and
prevent this, but it never hurts to have another look! Thanks for your
efforts with this one.

how this problem solved? i still have this problem, i am using cilent version 1.0.7...

There is a different know bug with file downloads open at the moment. I expect you are experiencing that.

This bug was specifically to do with the client never attempting to download files after a certain period. Take a look at: https://bugs.launchpad.net/xibo/+bug/613209

Also given that you're paying nothing for this software, and that the people who are helping you here are doing so on an unpaid voluntary basis you may find using more polite language than "How is this problem solved?" gets you a better response. You are not "entitled" to support, bugfixes - or indeed anything from any of us. If you know better - go and fix your problem yourself.