Failed to broadcast the transaction

[38PTSWarrior]

The time for my BTS claim from broadcasting to expiring is 120 seconds.

I want to tell the browser to give more than 15 secs but don't understand your guide.

Sorry, I missed this reply.  This is continued in the ticket you created:

https://github.com/cryptonomex/graphene-ui/issues/583

Thanks

[jamesc]

The time for my BTS claim from broadcasting to expiring is 120 seconds.

I want to tell the browser to give more than 15 secs but don't understand your guide.

Sorry, I missed this reply.  This is continued in the ticket you created:

https://github.com/cryptonomex/graphene-ui/issues/583

[38PTSWarrior]

Have the exact same problem like bitAndy. Toggling time from auto to manual did not work.
Good to know that you made a bug report.

Have to wait but it's OK
Obits, Metafees  hey hey
Fix real quick so I can buy
The assets which go to the sky

Maybe it is a time zone problem.  The server is in GMT+5 (Eastern Standard Time), you can put your clock to EST.

Here is what has been done so far....   One of the tests is this:  test in FF and Chrome by moving my timezone across the world.  The new time did show up in JavaScript but yet I was able to get the claim through ( it did not expire ).  Details below..

Some changes were made ( on good direction from DL ).  This change was committed on Oct 5th:

                // With a lot of balance claims the signing can take so Long
                // the transaction will expire.  This will increase the timeout...
                tr.set_expire_seconds(config.expire_in_secs + balance_claims.length)

One second per signature is probably 10 to 50 times longer that we need, I did check this at the time.  The config.expire_in_sec is only 15 seconds, this is done on purpose to keep the UI and the blockchain state consistent ( more on that below ).

Also, if you have many balance claim entries you will see multiple lines in the UI so you can check off and claim them separately.  This will group balance claims in the UI by groups of 60:

                // Signing is very slow, further divide the groups based on the number of signatures required
                var batch_number = Math.ceil( groupCount(Immutable.List([names, v.balance.asset_id]), v.owner) / 60 )

The expiration is based off of this time ( open the wallet and this will run in the browser's console ):

               ChainStore.getHeadBlockDate().toISOString()

The ISO date string returned above should show an accurate Zulu time regardless of you local clock time and regardless of your timezone.   Google printed the current Zulu time when I queried for it: https://www.google.com/?q=zulu%20time .. Also ChainStore.getHeadBlockDate().getTime() will be very stable too (other than milliseconds that go by between the timezone change).  Finally, I verify that the timezone change is seen immediately in the browser by running: new Date().toString()

If it is expiring, how many seconds pass after you click "Confirm" on the transaction confirm dialog?  Are these issues related to older versions of the browser?

The time for my BTS claim from broadcasting to expiring is 120 seconds.

I want to tell the browser to give more than 15 secs but don't understand your guide.

[38PTSWarrior]

Hi, I used 3g connection today and was able to import a few assets. But BTS and USD are still expiring. After the other assets went through I believe that it has nothing to do with the system time which has only 0,5 sec difference when checking time.is.

How do
I give it more than 15 seconds? It's difficult..

In the console of the browser this mistakes happens:
Error: 10 assert_exception: Assert Exception(…)

[jamesc]

Have the exact same problem like bitAndy. Toggling time from auto to manual did not work.
Good to know that you made a bug report.

Have to wait but it's OK
Obits, Metafees  hey hey
Fix real quick so I can buy
The assets which go to the sky

Maybe it is a time zone problem.  The server is in GMT+5 (Eastern Standard Time), you can put your clock to EST.

Here is what has been done so far....   One of the tests is this:  test in FF and Chrome by moving my timezone across the world.  The new time did show up in JavaScript but yet I was able to get the claim through ( it did not expire ).  Details below..

Some changes were made ( on good direction from DL ).  This change was committed on Oct 5th:

                // With a lot of balance claims the signing can take so Long
                // the transaction will expire.  This will increase the timeout...
                tr.set_expire_seconds(config.expire_in_secs + balance_claims.length)

One second per signature is probably 10 to 50 times longer that we need, I did check this at the time.  The config.expire_in_sec is only 15 seconds, this is done on purpose to keep the UI and the blockchain state consistent ( more on that below ).

Also, if you have many balance claim entries you will see multiple lines in the UI so you can check off and claim them separately.  This will group balance claims in the UI by groups of 60:

                // Signing is very slow, further divide the groups based on the number of signatures required
                var batch_number = Math.ceil( groupCount(Immutable.List([names, v.balance.asset_id]), v.owner) / 60 )

The expiration is based off of this time ( open the wallet and this will run in the browser's console ):

               ChainStore.getHeadBlockDate().toISOString()

The ISO date string returned above should show an accurate Zulu time regardless of you local clock time and regardless of your timezone.   Google printed the current Zulu time when I queried for it: https://www.google.com/?q=zulu%20time .. Also ChainStore.getHeadBlockDate().getTime() will be very stable too (other than milliseconds that go by between the timezone change).  Finally, I verify that the timezone change is seen immediately in the browser by running: new Date().toString()

If it is expiring, how many seconds pass after you click "Confirm" on the transaction confirm dialog?  Are these issues related to older versions of the browser?

[38PTSWarrior]

Have the exact same problem like bitAndy. Toggling time from auto to manual did not work.
Good to know that you made a bug report.

Have to wait but it's OK
Obits, Metafees  hey hey
Fix real quick so I can buy
The assets which go to the sky

[donkeypong]

I had to try three different browsers in Windows 8; Explorer or whatever they call it now was the only one that worked; Chrome and FireFox did not. And try both OpenLedger and the Light Client. Another forum member gave me the tip that maybe I also needed to update the system clock on my computer. It was set to automatically update, so I'm not clear on why there was any problem, but I re-toggled that anyway and suddenly the import worked.

[unreadPostsSinceLastVisit]

try going to settings wallet management, balance claims (or claim balance, dont remember off hand) instead of import.

[bitAndy]

Tried importing the unclaimed balances again.

''This wallet has already been imported.''

Can't see funds yet. But i'll try again when there's a fix.

[bitAndy]

I have 4 accounts, only one with balance on it.

#of keys

First account/ name: ''Keeping 17 of 19'' (with the funds)
2nd, 3rd and 4th : Keeping 1 of 1

[xeroc]

We saw some of these already. I reopend the bug report: https://github.com/cryptonomex/graphene-ui/issues/456

Rest assured that we can fix this .. your funds are safe .. it's just a matter of how we optimize your code so that people don't run into the very same problem again.
Could you tell us how MANY keys/balances there are? (Not the amounts)

[bitAndy]

I tried to import keys from my 0.9.3 wallet to the 2.0 light wallet. However after trying to broadcast the change the following appeared;

''Failed to broadcast the transaction:
now <= trx.expiration:''

Any advice on how I transfer the funds over?

It's windows 8 if that makes a difference.