(No viewer tab open, just one instance of browser) (I also optimised the db with maintenance) Glad this bug is being talked about, cos I hit against it couple of weeks back while trying to rate all the pics I upload to web.
#XNVIEWMP RATING DATA CODE#
So my guess without knowing the code so far is that something in the loading thread isn't 100% fail safe and is killing the thread instead of skipping the current image it's trying to load. It also doesn't seem to be a certain file, I've tried various combinations of images of more than 250 and I'm always ending up with 141, sometimes I even ended up with less but mosttimes it comes down to 141 survivors. It also seems that the loading thread exits prematurely, maybe the loading of one file fails for whatever reason and kills is and with that nuking all others past it too.Įdit: yeah it seems to be the thread crash that's causing the loss, I listed 181 R1's and let it list something else before it reached the breaking point, then re-listed them and it were 181, then I let it reach the breaking point and it were 141 again. Though now after re-listing a few times even with that on none but the first 141 survive. That's with "export rating / color to XMP" off, with that on most will survive the first re-listing, but they will still become less and less the more often I re-list them. List something else and then the used rating / color again and it'll be only the first 141 now List by that rating or color, they will be the original amount of imagesīut now, only the first 141 will actually keep their rating / color, the rest will forget it already when just scrolling down in the browser Just to chime in, I can make my Ratings and Colorings go away with the following procedure which is 100% reproducable for me: I presume that means xnview is doing all its own date/time calculations.
That would explain why "sqlite expert" could not interpret the dates.
#XNVIEWMP RATING DATA ISO#
I'm not sure whether it is significant, but the dates seem to be stored as strings like "20131106 13:12:14", while the sqlite3 ref says the strings should be iso format, with dashes separating year, month and day. Two instances of XnViewMP can apparently share the db file, but I suppose that is by design.
The results are basically as before - at the time XnViewMP re-opens a folder, the ratings and colours in the db are zeroed, except when the file modification time has been separately updated and there are xmp ratings in the file. appdata/roaming/xnviewmp folder so it would reconfigure itself with default options under win-7 圆4 and I then removed the default "keep original date/time for saving" option.Īfter baffling myself for a while with different results depending on program running order I finally settled on running XnViewMP, using sqlite3 command line program to examine the current db state and then exiting. I don't think these are exposed through the mapped drive interface, but just to be sure I copied the folder to a local drive and reran the tests. So the results depend on what order I open the programs.Īlso, the previous tests were run with the test folder on a shared samba server, and I discovered that the file modification times include fractional seconds. It seems as if MP refuses to write anything to XnView.db if it is already opened by another program. It looks like some of the previous debugging might be a bit less rigorous than I had hoped.
0 kommentar(er)
