Hello!
To use the forum, login or register above.
(If you are already logged in above, please click here)
Bricksync Warning
Hello,
i've used this incredible software for a long time and now i have this warning message every time i blmaster on/off:
WARNING: BrickOwl HTTP Error - Saving server reply (389+47 bytes) at path "data/errors-2017-09-22/00234.txt".
WARNING: Error creating BrickOwl item "3068bpb0959", color 2.
WARNING: It's possible we may have cached an old BOID for this BLID. Try updating the BLID<->BOID translation cache by typing owlqueryblid -f 3068bpb0959.
WARNING: The operation was rejected by BrickOwl. A further sync will attempt the operation again.
Here's the results of my owlqueryblid:
COMMAND: owlqueryblid -f 3068bpb0959
INFO: The BLID "3068bpb0959" resolves to the BOID 479744.
Anyone could help me?
Many thanks again
Regards,
Ale
i've used this incredible software for a long time and now i have this warning message every time i blmaster on/off:
WARNING: BrickOwl HTTP Error - Saving server reply (389+47 bytes) at path "data/errors-2017-09-22/00234.txt".
WARNING: Error creating BrickOwl item "3068bpb0959", color 2.
WARNING: It's possible we may have cached an old BOID for this BLID. Try updating the BLID<->BOID translation cache by typing owlqueryblid -f 3068bpb0959.
WARNING: The operation was rejected by BrickOwl. A further sync will attempt the operation again.
Here's the results of my owlqueryblid:
COMMAND: owlqueryblid -f 3068bpb0959
INFO: The BLID "3068bpb0959" resolves to the BOID 479744.
Anyone could help me?
Many thanks again
Regards,
Ale
Powered by Vanilla
Comments
https://www.brickowl.com/forum#/discussion/comment/26093
Then it was attached to the parent, now it's attached to 'medium stone gray'
I can only assume it was attached to the color back then and 'copied' to the noncolored, removed from the 'uncolored' but still under the color itself...
Thanks again
> I have about 9 of these errors, and some have been repeating for months. the owlforceblid doesn't fix the issues. So I guess I just have 9 lots that won't sync. Not sure what else to do.
I know Scooby Doo creates this error since BL considers them a minifig and BO an animal part
BrickSync has a few "safe" fallbacks for item types. For example, it checks if a set is a gear, if a gear is a set, if a part or minifig is a minibuild...
But it doesn't try all the BrickOwl item types for a given BLID because there are actual collisions in the map of BLIDs. There's a risk you could want to synchronize a part and end up adding a gear (it will try to resolve the part first, but perhaps the part's BLID wasn't yet set in the BrickOwl catalog). So I thought it was safer to miss a few items rather than perhaps synchronizing the wrong item...
There's certainly room for improvement though.
> BrickSync has a few "safe" fallbacks for item types. For example, it checks if a set is a gear, if a gear is a set, if a part or minifig is a minibuild...
Didn't know that, that's a nifty feature. I'm still having problems with gear/set 40158 though (Pirates Chess Set, Pirates III), any chance you could take a look at that one?
The reason for that is that BS doesn't hold any 'number' it just looks for a 'match' between 2 items on 2 different websites. If a match is clear e.g. S=10133-1 on BL is S=10133-1 on BO, then there is a 'match'.
In this case the Gear is 40158 on BL (no extention) and a Set 40158-1 on BO. Let's say 10 years from now TLG decides to make a new 'set' 40158, it will be 40158-1 on BL, but 40158-2 on BO, the BLID will need to be matched to the entry, but it can still lead to 'akeward' situations as the newer set 40158-1 might start syncing with 'older' set 40158-1 on BO (sidenote: already happens with '-0' sets of the entire CMF line -so don't list any-).
In think we can say this will probably never happen because TLG moved to 5 digit's for sets(and gear). (=89.999 new numbers, at 700-800 'set's per year, that's about 100 years of numbers ).
There are 2 ways to solve cases like that
1. by embedding certain 'preventions' (suggested to Alexis in the past) to avoid syncing (CMF-0 sets) as well as 'force match' between 2 items (regardless of itemtype) from within BS. It would mean a frequent 'adjustment' of BS, as well as a frequent update for the users to be up-to-date with these forced matches.
2. allow users to forceblid's by indicating the itemtype differs BOID S=336995 is BLID G=40158, unfortunatly, the latter would mean personal action from each user on each case, and might even be erased if a new BS is downloaded in future (not sure about that).
In both cases it would require some additional programming by Alexis, not even sure it's easy to do (I'm not a programmer). But at this point, it's pretty pointless he 'looks' at it, as his program does exactly what he is requesting: Skipping out items when there might be a possible 'conflict' = safety for sellers.
Sidenote: you can skip out the item from 'trying' to sync by putting the ~ sign in the remarks field on BL, then by manually listing on BO (also by adding the ~ sign in the personal description field) you can still have it listed. The only thing you need to remember is that you need to manually adjust on the other site in case it sells. I have a bunch of items like that, some listed on one site, some listed on the other (or might be listed, but in stockroom), I then simply add in my remark/personal field > not listed on XX, or 'to adjust manually on XX'. It's just a couple, the chances are slim they would be sold on the same date ;-)
If you encounter other errors like that, just post it on the forum and someone will figure out the problem (doesn't always mean there is a solution) ;-)
I have just tried with 40158 and BrickSync does try to create the item... but BrickOwl replies with "status":"Invalid condition". Oops.
I think there's a little mistake in the conversion of the condition types, when the item's type changes. BrickOwl is probably rejecting a "new" condition for a set (gear on BL), it must be "new sealed" or "new complete".
WARNING: Error creating BrickOwl item "5004928", color 0.
WARNING: It's possible we may have cached an old BOID for this BLID. Try updating the BLIDBOID translation cache by typing owlqueryblid -f 5004928.
WARNING: The operation was rejected by BrickOwl. A further sync will attempt the operation again.
And running "owlqueryblid" I get this:
COMMAND: owlqueryblid -f 5004928
INFO: The BLID "5004928" resolves to the BOID 75958.
> I think there's a little mistake in the conversion of the condition types, when the item's type changes. BrickOwl is probably rejecting a "new" condition for a set (gear on BL), it must be "new sealed" or "new complete".
Yeah, I'm guessing that's the problem. BL is inconsistent (once again). Not sure what the workaround would be, assuming new sets are sealed or not is tricky.
> @Razer I notice the bad BLID match has been removed by Admin. It is also attached to the correct 'egg' tile. So just sync again (BLmaster on/off for example) and it should be solved.
> If you encounter other errors like that, just post it on the forum and someone will figure out the problem (doesn't always mean there is a solution) ;-)
Of course! Thank you all guys
Many thanks
It's just a little bit problematic as I completely didn't foresee gear-set translations and the resulting mismatching item conditions... I had assumed the BOID was really all I needed, so BrickSync doesn't even track what an item's type is on BrickOwl, in neither BSX files or the translation cache. (and the translation cache would need a new format to accommodate the extra byte (no kidding, due to aggressive checksums to guard against partial/bad writes during a power shortage))
Well, BrickSync would be due for an update, there are several little details to fix like that one.
> @brickrepository There might be solution for this one, I filed an item type change, if Admin approves, it might start to sync afterwards (let us know).
That worked, kind of.
It sync-ed, but the price was showing as 0.01. But clicking through it, the price was "NOT NUMERIC", so I guess it wouldn't be possible to add to cart anyway. So I set the price again with BrickSync and it's now showing up correctly.
Thanks!
> Well, BrickSync would be due for an update, there are several little details to fix like that one.
I assume the sale percentages would also be stored in the translation cache? In that case it would be awesome if these could also be synced in the future!
> I assume the sale percentages would also be stored in the translation cache? In that case it would be awesome if these could also be synced in the future
The reason why sale percentages aren't synchronized is because there isn't a bulk API command to do that (on both BL and BO), each lot would have to be modified one at a time. And BL used to have a limit of 5000 API calls per day, so you could exhaust your daily pool just with a sale percentage update.
Unless the APIs are updated, it's much friendlier to the APIs to update sale percentages through their website interfaces...
> The reason why sale percentages aren't synchronized is because there isn't a bulk API command to do that (on both BL and BO), each lot would have to be modified one at a time. And BL used to have a limit of 5000 API calls per day, so you could exhaust your daily pool just with a sale percentage update.
Ah, I see. Thanks for explaining!