My guess is if you do a manual sync after an order comes in it'll sync. It won't do the automated sync when a new order comes in until they fix the API.
I updated bricksync to the latest release 1.7.2-3 (win64) from github, but now it's crashing at startup. It crashes at "Fetching BrickOwl user information".
I'm using the same config file as the previous bricksync.
Tried running a fresh installation of the release (no state file, no inventory) -> crash Tried running the old release -> crash Avast was giving a hard time about the new release, so I've disabled it -> still keeps crashing..
Anybody has a clue what could be the issue?
I haven't changed anything in the config file. Stores on BL and BO are still open and API keys haven't been changed.
This is what the log file shows: ========== Log Start ~ 2021-05-19 01:25:40 ==========
01:25:40 INIT: Launching BrickSync 01:25:40 INIT: Version 1.7.1 - Build Date Apr 2 2021 18:33:40 01:25:40 INIT: Operating System : Unknown, (build 19041 ), 64-bit 01:25:40 INIT: Work directory is "....\BrickSync\bricksync-win64-1.7.2-3\bricksync-win64". 01:25:40 INIT: Loading configuration at "data\bricksync.conf.txt". 01:25:40 INIT: Configuration loaded. 01:25:40 INIT: Resolving IP addresses for API and WEB services. 01:25:40 LOG: Resolved api.bricklink.com as 54.208.233.87 01:25:40 LOG: Resolved www.bricklink.com as 54.208.233.87 01:25:40 LOG: Resolved api.brickowl.com as 51.89.180.223 01:25:40 INFO: No BrickSync state file found! 01:25:40 INFO: We will create a new state file as "....\BrickSync\bricksync-win64-1.7.2-3\bricksync-win64\data\bricksync.state". 01:25:40 INIT: Fetching BrickOwl user information...
These color names are problematic. I would use the underlying color code number and [waves hands] "whatever" with the names.
BL's colors are <option value="8">Brown</option> <option value="120">Dark Brown</option> <option value="106">Fabuland Brown</option> <option value="91">Light Brown</option> <-- used to be Medium Brown, I think <option value="240">Medium Brown</option> <-- the "new" Brown <option value="88">Reddish Brown</option>
That doesn't really solve the problem... Medium Brown on BL maps to what on BrickOwl? It may just be that Medium Brown does not yet exist on BrickOwl, so we can't create a map yet. That may also be causing the new Medium Brown parts to be listed as Dark Flesh variants? Not sure.
Medium Dark Flesh is equivalent to BL's Medium Nougat, not Medium Brown. If the mapping is wrong in BrickSync then it the code needs changing if possible.
@Hoddie no issue with BrickSync. The code hasn't been changed to account for the new Medium Brown as yet. On taking a look at some of the newly released Medium Brown parts, it was odd to me that some were listed as Dark Flesh and some as Medium Dark Flesh here on BrickOwl. I would have thought they'd all have the same colour.
Hmmm. Then that suggests the inventory data is simply wrong - either the inventory has been manually changed/added or it has been imported that way from Lego.
If you look on BO's page of colours (link at the bottom of every page), Dark Flesh corresponds to Lego's Brown (colour id 217) and Medium Brown (503), while Medium Dark Flesh corresponds to Medium Nougat (312).
In theory there should be no clash. But it may also be that there used to be a clash and it has since been fixed perhaps.
BrickSync has bugs. It sometimes subtract or add to the inventory for no reason. Like it did today with a few lots. It's all visible in the log file too.
I have for a long time suspected there are issues with it. In the past I also tracked down what was going on with one particular lot and the BrickSync log indeed showed it had suddenly added quantity to a lot and we ended up being short of it for an order. Today it was the other way, it subtracted quantities from 5 random lots for the BO inventory. That was fixable by having it do a sync with BL. I don't have much confidence in it anymore but not much choice.
I have been unable to track down errors, where complete lots just disappear! Literally hundreds of parts just go. Every time I run through the logs I can't find any discrepancies.
I have closed my store on BO and stopped Bricksync for this reason. Hopefully at @ErwinNL gets the software operational soon.
There is a comment section on git hub? For comments/issues with Bricksync someone responds. But I dont know what to report as I cant find the errors!
@bricksinbins Are there any errors in the log prior to the item changes? Or any sign that BS wants to do a deep sync? And are the item changes only to BO or also to BL?
I have been running BS for a few years now and never noticed any issues with it, other than some mistakes of my own. Changing BL inventory and not doing a BLmaster in BS for example, not a very big issue, until BS does a deep sync and reverses the changes made
^ Same here, I have found multiple times that Bricksync is not forgiving if you aren't extremely precise with it. But randomly deleting lots, never seen that.
Just joking of course, I had BrickSync running as well but never experienced that but you are not the first I hear about it, so maybe there is an issue... I don't know... sync can really be complicated.
I do know that BrickSync picks the wrong mold/boid sometimes, because when converting from BL to BO it looks for matching IDs by iterating over each item type and picking the first one available. Sometimes this goes wrong, my sync wont do that but instead ask you what the correct match is.
This should be a little bit more work but end up being more accurate, perfect is sadly not possible because the data we work with isn't perfect.
@BasKrie The incident last week happened after I marked an order as Packed on BL. Then BS decides to subtract a few random lots in the order from the BO inventory. It was mostly pure luck I noticed it because it flagged a negative quantity for one of the lots. That lot had just been picked and I knew it obviously did not have a negative count.
Taking a closer look at the log leading up to this, I see BS had created and added these lots to BO inventory earlier in the day, again for no apparent reason. Before that I had done a blmaster on/off because I added a few items to inventory (completely unrelated to these lots).
I'm now starting to think the blmaster on/off command has something to do with this. I know in the past we have discovered inventory errors that could stem from inventory changes and the blmaster command. What exact sequence of events that triggers it are, I can't say.
There is a known bug with blmaster when BL orders are 'in progress'.
Order items are moved out of your BL inventory and into a stockroom when an order is 'in progress'. If you run a blmaster during this time, those items that have been moved into the stockroom will get removed from the BS master database and BrickOwl. If the 'in progress' order is then released, the items get moved back into your BL inventory from the stockroom.
So at this point, your BL inventory would be correct, but the BS master database and BO are wrong.
Now another blmaster would correct everything, but if any sync's happen the BL inventory will be adjusted to match the master database... and remove the now-released items. Likewise, if any orders come in that include any items that were previously 'in progress', the stock qty will be adjusted based on the BS master database qty (potential negative qty errors).
I'd imagine it's relatively rare that the string of events here happens, but it's possible. It came to light about 12 months ago when BL had a problem with orders getting stuck 'in progress' for days and even weeks.
So BS has bugs even though some want to blame everything on user error. Well this is certainly very good to know. So if I understand this correctly... If I do a blmaster when orders are in progress (I assume this means they are not marked as shipped?) this will mess up the inventory. But doing another blmaster again, will sort it out? Again, I'd assume that blmaster needs to be after orders are finished? That seems to be what I did and it did sort things out as far as I could tell.
Orders in progress has to do with instant checkout. Items in order are removed from inventory so that other buyers can't buy them but the order is only entered into the system when payment is made through Paypal or Stripe. This can cause problems if you do a blmaster while an order is in progress.
I attempted to cause that. Using my wife's BL account to "buy" from my store, leaving the order NOT completed on BL, having gone thru the redirect to PayPal. Did BL master on/off. No error occurred.
What I an having is complete lots disappearing, 1x4 plates in MSG/LBG has happened at least twice. Also happened to 1x2 plates MSG, 2x8 plates MSG. 2x2 bricks Thinking about it - it seems to be only MSG/LBG and DSG/DBG that get wiped out
@paulvdb I see, that's an important detail I have not thought about. I upload partouts via the BL web page so I can get cost values in properly. Not sure if that is possible via BS commands.. Looking at the BS commands now, loadmycost will replace the mycost and that is not what I want. Not sure if loadall does a replace or combine with existing..
I feel the web interface is the way to go but it should not be done if there are unpaid orders to avoid problems.
@bricksinbins - it's not a bug with the program, rather it was written before BL decided how to handle orders made via instant checkout.
Using blmaster correctly ends with the program doing a minor sync with BO, but it cannot possibly know that BL has shifted items into a stockroom pending an order being finalised. It simply assumes that you've deleted those items from your inventory during your blmaster session, and proceeds to remove them from BO. Then when the order finalises and BruckSync becomes aware of it, it proceeds to remove them from BO again. If it encounters a negative quantity this may in turn trigger a full sync, at which point it's down the rabbit hole with any number of unintended consequences. All this is incredibly unlikely to happen but it can if you leave blmaster just as BL is dealing with an order received via instant checkout.
blmaster should not be used now it's known that this situation exists. BrickSync works perfectly otherwise (not withstanding the issue Graham is reporting, which has yet to be nailed down). Every issue that I've ever investigated for anyone, probably a couple of dozen or more, has been traced back to user error with blmaster
blmaster was included because Stragus (the original author) knew that many sellers preferred to update their inventory on BL rather than via BrickSync. The program can be used without ever entering blmaster, as it can import bsx files for 'parting out' and individual lots can be searched for and amended very easily.
In theory, the other syncing options available could also be hit by this issue, but perhaps they have built checks into their code that mitigates the risk (and maybe even remove it entirely).
Gross, 1% off the top. I assume that most people who use bricksync use it because it gives them a crazy amount of control over their inventory. I have years of backups/orders and can run a manual sync any time I want to because that one time I had 2 people buy the same thing still bugs me.
I would say that is an intended behavior that is really hard to fix, but it is easy to prevent, just don't do a blmaster off if the In Progress has a number greater than 0.
Comments
Brexit, the gift that keeps on not giving.
What did you do? I still get the same "Internal_Server_Error"
Did you restart your computer or anything like that?
It crashes at "Fetching BrickOwl user information".
I'm using the same config file as the previous bricksync.
Tried running a fresh installation of the release (no state file, no inventory) -> crash
Tried running the old release -> crash
Avast was giving a hard time about the new release, so I've disabled it -> still keeps crashing..
Anybody has a clue what could be the issue?
I haven't changed anything in the config file.
Stores on BL and BO are still open and API keys haven't been changed.
This is what the log file shows:
========== Log Start ~ 2021-05-19 01:25:40 ==========
01:25:40 INIT: Launching BrickSync
01:25:40 INIT: Version 1.7.1 - Build Date Apr 2 2021 18:33:40
01:25:40 INIT: Operating System : Unknown, (build 19041 ), 64-bit
01:25:40 INIT: Work directory is "....\BrickSync\bricksync-win64-1.7.2-3\bricksync-win64".
01:25:40 INIT: Loading configuration at "data\bricksync.conf.txt".
01:25:40 INIT: Configuration loaded.
01:25:40 INIT: Resolving IP addresses for API and WEB services.
01:25:40 LOG: Resolved api.bricklink.com as 54.208.233.87
01:25:40 LOG: Resolved www.bricklink.com as 54.208.233.87
01:25:40 LOG: Resolved api.brickowl.com as 51.89.180.223
01:25:40 INFO: No BrickSync state file found!
01:25:40 INFO: We will create a new state file as "....\BrickSync\bricksync-win64-1.7.2-3\bricksync-win64\data\bricksync.state".
01:25:40 INIT: Fetching BrickOwl user information...
But I've also tried that and it still crashes.
I finally figured it out...
Looks like I did make a change in the config file when I did the first update.
This setting:
// Set to zero if you don't want to check for new versions of BrickSync or any broadcast message
checkmessage = 1;
I had it changed to 0 and that was the reason of the crashes.....
Back to 1 and it works!
Tyson
Latest update available here... https://github.com/ZZJHONS/Bricksync
The browns need sorting, but I'm honestly confused.
Item No: 6382551
On BrickOwl, colour is Dark Flesh.
On BL, colour is Medium Brown.
Item No: 6373424
On BrickOwl, colour is Medium Dark Flesh.
On BL, colour is Medium Brown.
So we have different colours on BrickOwl, but the same colour on BL??
If anyone can clear that up for me, feel free
These color names are problematic. I would use the underlying color code number and [waves hands] "whatever" with the names.
BL's colors are
<option value="8">Brown</option>
<option value="120">Dark Brown</option>
<option value="106">Fabuland Brown</option>
<option value="91">Light Brown</option> <-- used to be Medium Brown, I think
<option value="240">Medium Brown</option> <-- the "new" Brown
<option value="88">Reddish Brown</option>
But check Randy's post linked above.
It may just be that Medium Brown does not yet exist on BrickOwl, so we can't create a map yet.
That may also be causing the new Medium Brown parts to be listed as Dark Flesh variants? Not sure.
On taking a look at some of the newly released Medium Brown parts, it was odd to me that some were listed as Dark Flesh and some as Medium Dark Flesh here on BrickOwl. I would have thought they'd all have the same colour.
If you look on BO's page of colours (link at the bottom of every page), Dark Flesh corresponds to Lego's Brown (colour id 217) and Medium Brown (503), while Medium Dark Flesh corresponds to Medium Nougat (312).
In theory there should be no clash. But it may also be that there used to be a clash and it has since been fixed perhaps.
I have been unable to track down errors, where complete lots just disappear! Literally hundreds of parts just go. Every time I run through the logs I can't find any discrepancies.
I have closed my store on BO and stopped Bricksync for this reason. Hopefully at @ErwinNL gets the software operational soon.
There is a comment section on git hub? For comments/issues with Bricksync someone responds. But I dont know what to report as I cant find the errors!
Are there any errors in the log prior to the item changes?
Or any sign that BS wants to do a deep sync?
And are the item changes only to BO or also to BL?
I have been running BS for a few years now and never noticed any issues with it, other than some mistakes of my own.
Changing BL inventory and not doing a BLmaster in BS for example, not a very big issue, until BS does a deep sync and reverses the changes made
Just joking of course, I had BrickSync running as well but never experienced that but you are not the first I hear about it, so maybe there is an issue... I don't know... sync can really be complicated.
I do know that BrickSync picks the wrong mold/boid sometimes, because when converting from BL to BO it looks for matching IDs by iterating over each item type and picking the first one available. Sometimes this goes wrong, my sync wont do that but instead ask you what the correct match is.
This should be a little bit more work but end up being more accurate, perfect is sadly not possible because the data we work with isn't perfect.
Taking a closer look at the log leading up to this, I see BS had created and added these lots to BO inventory earlier in the day, again for no apparent reason. Before that I had done a blmaster on/off because I added a few items to inventory (completely unrelated to these lots).
I'm now starting to think the blmaster on/off command has something to do with this. I know in the past we have discovered inventory errors that could stem from inventory changes and the blmaster command. What exact sequence of events that triggers it are, I can't say.
Order items are moved out of your BL inventory and into a stockroom when an order is 'in progress'.
If you run a blmaster during this time, those items that have been moved into the stockroom will get removed from the BS master database and BrickOwl.
If the 'in progress' order is then released, the items get moved back into your BL inventory from the stockroom.
So at this point, your BL inventory would be correct, but the BS master database and BO are wrong.
Now another blmaster would correct everything, but if any sync's happen the BL inventory will be adjusted to match the master database... and remove the now-released items. Likewise, if any orders come in that include any items that were previously 'in progress', the stock qty will be adjusted based on the BS master database qty (potential negative qty errors).
I'd imagine it's relatively rare that the string of events here happens, but it's possible.
It came to light about 12 months ago when BL had a problem with orders getting stuck 'in progress' for days and even weeks.
So if I understand this correctly... If I do a blmaster when orders are in progress (I assume this means they are not marked as shipped?) this will mess up the inventory. But doing another blmaster again, will sort it out? Again, I'd assume that blmaster needs to be after orders are finished?
That seems to be what I did and it did sort things out as far as I could tell.
What I an having is complete lots disappearing, 1x4 plates in MSG/LBG has happened at least twice. Also happened to 1x2 plates MSG, 2x8 plates MSG. 2x2 bricks Thinking about it - it seems to be only MSG/LBG and DSG/DBG that get wiped out
I feel the web interface is the way to go but it should not be done if there are unpaid orders to avoid problems.
Using blmaster correctly ends with the program doing a minor sync with BO, but it cannot possibly know that BL has shifted items into a stockroom pending an order being finalised. It simply assumes that you've deleted those items from your inventory during your blmaster session, and proceeds to remove them from BO. Then when the order finalises and BruckSync becomes aware of it, it proceeds to remove them from BO again. If it encounters a negative quantity this may in turn trigger a full sync, at which point it's down the rabbit hole with any number of unintended consequences. All this is incredibly unlikely to happen but it can if you leave blmaster just as BL is dealing with an order received via instant checkout.
blmaster should not be used now it's known that this situation exists. BrickSync works perfectly otherwise (not withstanding the issue Graham is reporting, which has yet to be nailed down). Every issue that I've ever investigated for anyone, probably a couple of dozen or more, has been traced back to user error with blmaster
blmaster was included because Stragus (the original author) knew that many sellers preferred to update their inventory on BL rather than via BrickSync. The program can be used without ever entering blmaster, as it can import bsx files for 'parting out' and individual lots can be searched for and amended very easily.
In theory, the other syncing options available could also be hit by this issue, but perhaps they have built checks into their code that mitigates the risk (and maybe even remove it entirely).