File sorting does not update / show correctly when using by Upload date (descending)

[hoegge]

What were you doing?

1. Set file sorting to "Upload date (descending)
2. Upload a new file
3. It will not be shown at the top

What did you expect to happen?

Last uploaded file first

What happened instead?

Last uploaded file second.
Trying to resort or change sort order or reload page does not correct it

Did the same happen when running OctoPrint in safe mode?

Have not tried

Version of OctoPrint

Version 1.3.6

Operating System running OctoPrint

OctoPi

Printer model & used firmware incl. version

not relevant

Browser and Version of Browser, Operating System running Browser

Chrome PC latest

Link to octoprint.log

https://www.dropbox.com/s/zsi9of5fmungz9o/octoprint.log?dl=0

Link to contents of terminal tab or serial.log

https://www.dropbox.com/s/uhkn64lil6np5fi/Terminal%20tab.txt?dl=0

Link to contents of Javascript console in the browser

https://www.dropbox.com/s/lo1d123rri9fk35/browser%20console%2010.10.1.26-1515672229697.log?dl=0

Screenshot(s)/video(s) showing the problem:

[GitIssueBot]

Hi @hoegge,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2018-01-25 10:20 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[foosel]

Please provide all requested information. Without that information this ticket cannot be looked into and will be closed. Thanks.

[hoegge]

@foosel It "can" be looked at but maybe you won't ;-) Not all the information is relevant (terminal, printer type) for a file upload and display problem or? I have added Octoprint log and Chrome console data.

[foosel]

It can be looked at if it's the only ticket. It isn't, and running after information simply doesn't scale from a certain point, sorry. By providing all requested information you make sure your problem can be tackled in a timely manner, without endless round trips to request additional information. Isn't that worth the minimum overhead of collecting some logs?

[ScottWell1]

FYI... I have seen this problem when I manually (via SCP) created a folder in .octoprint/uploads and moved some of the files from .octoprint/uploads into the new folder. After doing that, new files uploaded did not sort correctly. I suspect it has something to do with the .metadata.yaml file being out-of-sync with the folder content after the manual file/folder changes. Deleting .metadata.yaml and letting it be regenerated fixed the problem for me.

[hoegge]

What information is missing? Would be smart if the automated mail said what was missing, I can't see what. Octoprint does often not sort correctly by time and I now have the same problem on a new Octopi/Octoprint, so probably not a one off.

[foosel]

No information is missing since the OP added what was missing (logs and js console). I so far have not been able to reproduce this though, so any additional information regarding reproduction steps will be helpful.

[foosel]

I still cannot reproduce this following the above steps. Also not via external modification of the uploads folder as indicated by @ScottWell1 (which - btw - is completely unsupported).

If anyone happens to run into this and can provide reliable reproduction steps, I'm happy to look into this further, but for now I'm marking it as unreproduced.

[hoegge]

Ok, will try to see if I can find a way to reproduce it. E.g. my list right now looks like this:

[hoegge]

BTW, does the color of the filenames have any influence? Sometimes some are red, sometimes some are green and sometimes black. Could not find the reason in the documentation.

[arhi]

@hoegge red ones failed to print, green one printed successfully, black ones you did not try to print yet

[BETLOG]

Version 1.3.8
I just had this happen. It is obviously intermittent, as I have only noticed it once before (a few days ago) and corrected it by deleting all files in my queue list except the oldest (a test file).
The most recently queued file was not listed at the top. I always sort by upload date, re-selecting this, or choosing another option and then reselecting date did not correct the list.
Today when I noticed it happening again I deleted a much older and unrelated file (the second file from the bottom of the list) and the correct sequencing re-asserted itself. I had accidentally begun printing an older file (that was incorrectly listed at the top) shortly before doing this.
It may not be related, but I have recently installed "Print History Plugin (1.2)"

[BETLOG]

And again

[foosel]

I still haven't been able to reproduce this myself. Does this also happen in safe mode?

[BETLOG]

With a file list that is clear of all but one file, I cannot reproduce it in safe or normal mode.
But unlike my previous experience of the issue I do not have files in the list that are more then a day old to compare. I will avoid removing entries until tomorrow, and retry.

[foosel]

@BETLOG anything new on that test?

[BETLOG]

@foosel unfortunately not. Not noticing that I had inverted the connector on a piezo pcb has progressively fried two of my 3 arduinos regulators. So my printer has been completely inactive since our last posts. I was however not able to duplicate the issue even when attempting to do so.

[foosel]

@BETLOG sorry to hear about the fried electronics :/ But good to know that you haven't been able to reproduce it so far anymore, I was starting to think I was doing something excessively differently than all of you.

[BETLOG]

Hahah. Such is the nature of these things :)
I have been printing and sending/deleting small test files all day, with some being several weeks old, but so far I have not reproduced it. ...Or at least not like last time; when the topmost file was not the expected one. I have not been paying particular attention to the precise order of the later files, but superficially I'm pretty sure nothing is out of place.
I don't get it, either.

[adrianmihalko]

I have similar problem. I set Sorty by upload date, but this setting is then not saved. Is there any trick to make it work?

[BETLOG]

The trick is to figure out how to reproduce it, or why it's happening, so foosel can fix it. :)

Try deleting a single older file.

[BETLOG]

Well, I managed to duplicate this issue a few days ago, but I have no idea how or why. I was just queuing a file and it wasn't at the top of the list. I have left the offending file at the top of the list and deleted a few files under it, but everything I queue ends up in the correct chronological sequence... under a file that is several days old. Very strange. So it therefore it looks like my glib suggestion of "delete a file" should be "delete the out of place/top file".

[ScottWell1]

@BETLOG - Before deleting anything else (i.e., while the condition exists) try to gather as much information as possible. At very least, SSL in and capture a directory listing (ls -alt) of the uploads folder, and get a copy of the ".metadata.yaml" file.

@foosel -- What other data, tests, or logging might be useful?

[BETLOG]

[edit] Sorry, i'll break those files up henceforth...
OctoPrint-issues-2355__metadata.yaml.txt
OctoPrint-issues-2355__octoprint.log.txt
OctoPrint-issues-2355__uploads.txt

[BETLOG]

And as if by magic.. it works again....
All I did was queue a bunch of stl's dragged into the same Slic3r scene and send to printer.
Note that the file that was previously incorrectly on top of the list, is now still in the same sequence relative to the previous files, but the newly added file is (correctly) on top of them all.

[luke321]

I have the same problem over and over again, suddenly files that I uploaded some days ago get to the top of my sort by upload date file list:

I will also try to figure out what's going on to help reproduce the bug, what I can say:

• I uploaded the files via REST API call
• The file on top was printed 3-4 times
• The files in the wrong order were only printed once or not at all

Maybe printing a file messes with the internal upload date? Or upload time is used over the date for sorting?

Another strange thing, when I change the sorting to name and back to upload, the newest file is suddenly at the bottom:

After pressing refresh I get the order above.
When I delete some files another old file get's to the top, nothing changes when pressing refresh:

[BETLOG]

This time the file I queued did not go to the top of the list...But rather quite a long way down the list.

Also, possibly related: for no apparent reason a print in progress and at about Z=1mm suddenly started gouging the bed with the nozzle. As if the Z nemas had been inverted part way through a print. I've never seen anything like that before. Maybe this and the mis-sorting is a symptom of some kind of sdcard corruption on the pi? I have had some very unusual yet subtle behaviour because of that in the past. Seems unlikely though. For now I'm going to assume it's a separate issue, unrelated to octoprint.

OctoPrint-issue2355__.metadata.yaml_2018-05-15--19-11-32.txt
OctoPrint-issue2355__octoprint.log_2018-05-15--19-11-32.txt
OctoPrint-issue2355__uploads_2018-05-15--19-11-32.txt

[foosel]

@foosel -- What other data, tests, or logging might be useful?

Since the upload date is basically the creation/modification date as attached to the file on disk (the younger of the two IIRC), the output of ls -la ~/.octoprint/uploads would indeed be the most helpful here. If the data there is ok, I'm leaning towards some strange caching issues causing this, since the only place that data is stored is in fact on the filesystem metadata and the cache - metadata.yaml isn't involved in any way here, nor is any kind of internal OctoPrint logic.

[John-Mc]

@foosel - Could the problem be related to how the file gets to the uploads folder? I know you've mentioned in the past not to manually place files in the Uploads folder and not to Samba share the Uploads folder (we should create a Watched Folder and upload to that instead), since bypassing OctoPrint's normal method for getting files into the uploads folder caused some necessary "housekeeping duties" to be skipped.

[luke321]

@foosel My Octoprint is acting up again:

When reloading the page or pressing refresh the list is wrong:

When I switch to sort by name and back to sort by date it is correct until i reload or press refresh:

And here is the console ouput, the date and timestamps are in the correct order:

I uploaded MK3_OG.gcode via REST API from my own Python Gcode Postprocessor, but I am pretty sure I also had this when manually uploading files.

Can I give you any more information to get this bug?

[foosel]

@John-Mc Good idea, but that necessary house keeping doesn't involve the upload date. That's really just taken from the file metadata itself. Whatever ls -la shows should also be what OctoPrint sees. What also greatly confuses me is that it almost looks on those screenshots as if the dates are actually correct, it's just the sorting (which happens exclusively in the browser) that's off. Which I don't get because what happens there is the timestamps as retrieved from the backend (which in turn gets them from the file system) are simply sorted numerically by simple JS sorting functions, that should also not fail...

Long story short, this greatly confuses me. What might be interesting on top of an output of ls -la would actually be a full blown response body for the file list request from the server, which should be available in the network console (F12 at least in Firefox & Chrome, then switch to the "Network" tab):

@luke321 could you provide the above reponse headers and response body?

[luke321]

@foosel No problem:

Response headers:

HTTP/1.1 304 NOT MODIFIED
Cache-Control: max-age=0
X-Clacks-Overhead: GNU Terry Pratchett
Set-Cookie: session_P80=.eJxNjUELgjAcxb9K_M8SUh1i4M0cBVsUie0k1iYbThM3MSd-98QuOz0e7_3emyAvO2EkoLLQRgSQKw5ogs0LENA63VGchgSfHHEXyZyUNCZ7lp2HRQ-sZl_idHWNSQRzAIqLxio7boveytyOrQDU9Fp7ibf-xtVK9UZ06yu0Cv7WCGPUp_Hb90fiWHgcsmdC-S1ayPkH2aM9kA.DdyIYQ.WBVlgiO0xzmcRdOLFu77IXlD6H8; Path=/; HttpOnly
X-Robots-Tag: noindex, nofollow, noimageindex

response body:

{"files": [{"date": 1526378199, "display": "MK3_akkus.gcode", "gcodeAnalysis": {"dimensions": {"depth": 137.13, "height": 4.799, "width": 164.275}, "estimatedPrintTime": 9382.315677075881, "filament": {"tool0": {"length": 6135.963800001853, "volume": 0.0}}, "printingArea": {"maxX": 164.275, "maxY": 134.13, "maxZ": 4.799, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "02c79c756faeae48159e815d3d50fdcd2d260a28", "name": "MK3_akkus.gcode", "origin": "local", "path": "MK3_akkus.gcode", "refs": {"download": "http://10.0.0.20/downloads/files/local/MK3_akkus.gcode", "resource": "http://10.0.0.20/api/files/local/MK3_akkus.gcode"}, "size": 1823665, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"children": [{"date": 1520490332, "display": "pla_test.gcode", "gcodeAnalysis": {"dimensions": {"depth": 112.785, "height": 1.999, "width": 144.785}, "estimatedPrintTime": 523.4055771781871, "filament": {"tool0": {"length": 333.16309999999385, "volume": 0.0}}, "printingArea": {"maxX": 144.785, "maxY": 109.785, "maxZ": 1.999, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "31d6a4a70521d86b86013431533ce76d0db29ca4", "name": "pla_test.gcode", "origin": "local", "path": "Calibs/pla_test.gcode", "prints": {"failure": 0, "last": {"date": 1520491042.95241, "printTime": 626.4699320793152, "success": true}, "success": 1}, "refs": {"download": "http://10.0.0.20/downloads/files/local/Calibs/pla_test.gcode", "resource": "http://10.0.0.20/api/files/local/Calibs/pla_test.gcode"}, "size": 108304, "statistics": {"averagePrintTime": {"_default": 626.4699320793152}, "lastPrintTime": {"_default": 626.4699320793152}}, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1519034572, "display": "prusa_ht_test.gcode", "gcodeAnalysis": {"dimensions": {"depth": 113.01, "height": 1.998, "width": 144.79}, "estimatedPrintTime": 271.4573236526969, "filament": {"tool0": {"length": 319.9139999999969, "volume": 0.0}}, "printingArea": {"maxX": 144.79, "maxY": 110.01, "maxZ": 1.998, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "170c7332b9ce4dac88788bbd3f1bc62c9847adbe", "name": "prusa_ht_test.gcode", "origin": "local", "path": "Calibs/prusa_ht_test.gcode", "refs": {"download": "http://10.0.0.20/downloads/files/local/Calibs/prusa_ht_test.gcode", "resource": "http://10.0.0.20/api/files/local/Calibs/prusa_ht_test.gcode"}, "size": 66476, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1525527602, "display": "MK3_Cleaner.gcode", "gcodeAnalysis": {"dimensions": {"depth": 0.0, "height": 0.0, "width": 0.0}, "estimatedPrintTime": 10.543088022903975, "filament": {"tool0": {"length": 50.0, "volume": 0.0}}, "printingArea": {"maxX": null, "maxY": null, "maxZ": null, "minX": null, "minY": null, "minZ": null}}, "hash": "bf085ffc120f44e88537aea2e859b0b12aa203f0", "name": "MK3_Cleaner.gcode", "origin": "local", "path": "Calibs/MK3_Cleaner.gcode", "prints": {"failure": 1, "last": {"date": 1526367568.851734, "printTime": 353.35611295700073, "success": true}, "success": 3}, "refs": {"download": "http://10.0.0.20/downloads/files/local/Calibs/MK3_Cleaner.gcode", "resource": "http://10.0.0.20/api/files/local/Calibs/MK3_Cleaner.gcode"}, "size": 166, "statistics": {"averagePrintTime": {"_default": 377.50834401448566}, "lastPrintTime": {"_default": 353.35611295700073}}, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1519034572, "display": "prusa_petg_test.gcode", "gcodeAnalysis": {"dimensions": {"depth": 113.01, "height": 1.998, "width": 144.79}, "estimatedPrintTime": 271.4573236526969, "filament": {"tool0": {"length": 319.9139999999969, "volume": 0.0}}, "printingArea": {"maxX": 144.79, "maxY": 110.01, "maxZ": 1.998, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "9d87913238e7bc883de1df3320812a6826d6545e", "name": "prusa_petg_test.gcode", "origin": "local", "path": "Calibs/prusa_petg_test.gcode", "prints": {"failure": 2, "last": {"date": 1521523968.762834, "printTime": 331.8189580440521, "success": true}, "success": 4}, "refs": {"download": "http://10.0.0.20/downloads/files/local/Calibs/prusa_petg_test.gcode", "resource": "http://10.0.0.20/api/files/local/Calibs/prusa_petg_test.gcode"}, "size": 66465, "statistics": {"averagePrintTime": {"_default": 342.99451518058777}, "lastPrintTime": {"_default": 331.8189580440521}}, "type": "machinecode", "typePath": ["machinecode", "gcode"]}], "display": "Calibs", "name": "Calibs", "origin": "local", "path": "Calibs", "refs": {"resource": "http://10.0.0.20/api/files/local/Calibs"}, "size": 241411, "type": "folder", "typePath": ["folder"]}, {"date": 1526318877, "display": "MK3_DACH.gcode", "gcodeAnalysis": {"dimensions": {"depth": 144.805, "height": 3.998, "width": 161.777}, "estimatedPrintTime": 2737.3659455981056, "filament": {"tool0": {"length": 3113.8162000000034, "volume": 0.0}}, "printingArea": {"maxX": 161.777, "maxY": 141.805, "maxZ": 3.998, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "6a1b6af39a52543d883e19fba3b8b0ecd7cb813c", "name": "MK3_DACH.gcode", "origin": "local", "path": "MK3_DACH.gcode", "prints": {"failure": 0, "last": {"date": 1526382103.303737, "printTime": 2851.8786981105804, "success": true}, "success": 3}, "refs": {"download": "http://10.0.0.20/downloads/files/local/MK3_DACH.gcode", "resource": "http://10.0.0.20/api/files/local/MK3_DACH.gcode"}, "size": 129313, "statistics": {"averagePrintTime": {"_default": 2852.6051319440207}, "lastPrintTime": {"_default": 2851.8786981105804}}, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1526377977, "display": "MK3_pedestrian_seitenrampe_1_18.gcode", "gcodeAnalysis": {"dimensions": {"depth": 140.103, "height": 5.499, "width": 169.963}, "estimatedPrintTime": 6890.6361372978945, "filament": {"tool0": {"length": 3177.804399999062, "volume": 0.0}}, "printingArea": {"maxX": 169.963, "maxY": 137.103, "maxZ": 5.499, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "66f9626fa68d520717b20d0eebcd2dc6a822a35a", "name": "MK3_pedestrian_seitenrampe_1_18.gcode", "origin": "local", "path": "MK3_pedestrian_seitenrampe_1_18.gcode", "refs": {"download": "http://10.0.0.20/downloads/files/local/MK3_pedestrian_seitenrampe_1_18.gcode", "resource": "http://10.0.0.20/api/files/local/MK3_pedestrian_seitenrampe_1_18.gcode"}, "size": 2951388, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1526395475, "display": "MK3_OG.gcode", "gcodeAnalysis": {"dimensions": {"depth": 145.41, "height": 19.998, "width": 161.909}, "estimatedPrintTime": 8748.627289925513, "filament": {"tool0": {"length": 8722.510100000882, "volume": 0.0}}, "printingArea": {"maxX": 161.909, "maxY": 142.41, "maxZ": 19.998, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "4b4bf7dfa19ae06db6b8c2e525bb0520e201efc9", "name": "MK3_OG.gcode", "origin": "local", "path": "MK3_OG.gcode", "refs": {"download": "http://10.0.0.20/downloads/files/local/MK3_OG.gcode", "resource": "http://10.0.0.20/api/files/local/MK3_OG.gcode"}, "size": 1457296, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1526377966, "display": "MK3_Axle_Wheel_Base.gcode", "gcodeAnalysis": {"dimensions": {"depth": 149.954, "height": 34.399, "width": 167.986}, "estimatedPrintTime": 15576.19483211746, "filament": {"tool0": {"length": 5435.034900006066, "volume": 0.0}}, "printingArea": {"maxX": 167.986, "maxY": 146.954, "maxZ": 34.399, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "e6ec6eebcb4c46c1cab4ae3ab6c698cefcf1f8a6", "name": "MK3_Axle_Wheel_Base.gcode", "origin": "local", "path": "MK3_Axle_Wheel_Base.gcode", "refs": {"download": "http://10.0.0.20/downloads/files/local/MK3_Axle_Wheel_Base.gcode", "resource": "http://10.0.0.20/api/files/local/MK3_Axle_Wheel_Base.gcode"}, "size": 20042271, "type": "machinecode", "typePath": ["machinecode", "gcode"]}, {"date": 1526310421, "display": "MK3_EG.gcode", "gcodeAnalysis": {"dimensions": {"depth": 145.41, "height": 21.998, "width": 161.909}, "estimatedPrintTime": 9475.4980902511, "filament": {"tool0": {"length": 9294.091600000518, "volume": 0.0}}, "printingArea": {"maxX": 161.909, "maxY": 142.41, "maxZ": 21.998, "minX": 0.0, "minY": -3.0, "minZ": 0.0}}, "hash": "99d9ea9f0ee07dcf54100d431ff21f7a732e9873", "name": "MK3_EG.gcode", "origin": "local", "path": "MK3_EG.gcode", "prints": {"failure": 0, "last": {"date": 1526394079.760677, "printTime": 11663.639322042465, "success": true}, "success": 3}, "refs": {"download": "http://10.0.0.20/downloads/files/local/MK3_EG.gcode", "resource": "http://10.0.0.20/api/files/local/MK3_EG.gcode"}, "size": 1936701, "statistics": {"averagePrintTime": {"_default": 11664.364645719528}, "lastPrintTime": {"_default": 11663.639322042465}}, "type": "machinecode", "typePath": ["machinecode", "gcode"]}], "free": 13025038336, "total": 15232843776}

The order is still incorrect with MK3_akkus before MK3_OG in the file list:

But when I reorder the list by selecting order by name and than order by date I get to correct order, so the data from the response should be correct right?

[foosel]

Yeah, it should, but now we know it is, which is better than should ;)

Ok, so this really smells like some kind of JS side sorting issue. I understand it only happens on refresh for you @luke321. What about the others? @BETLOG, @adrianmihalko, @ScottWell1, @hoegge can you fix it (until the next refresh) by switching to e.g. sort by name, then switching back to sort by upload date? I'm suspecting something being up with the local storage data (where the sorting preference is stored).

[ScottWell1]

What about the others? @BETLOG, @adrianmihalko, @ScottWell1, @hoegge can
you fix it (until the next refresh) by switching to e.g. sort by name, then switching back
to sort by upload date?

It has been a while since I had the problem but as best I recall....

YES - switching sort to "by name" and then back to "by upload date" resulted in correct order, but after refreshing the "offending older file" was at the top again. The date/time on the file itself was correct, and Octoprint correctly stated the "uploaded:" age of the file in the listing (as in examples posted by others above).

New files added (via watched folder) were inserted into the list below the older file; toggling sort order to name then back to descending date fixed it until a refresh or another file was added.

[BETLOG]

@foosel No, toggling sort option did not rectify my list. I have attempted that twice, several weeks apart. Neither time had the desired effect.
A few days ago my list started getting difficult to navigate (my long filenames, fast scroll speed, and the tiny unresizable list frame being the main frustrations) and new files became difficult to find, so I deleted everything. But at that time there were several files incorrectly above the latest one. Previously I only had one file incorrectly at top, and everything else correctly sorted under that.

[luke321]

@foosel Toggling the sort option did not always fix everything.
I had an instance which I describe in my first comment where toggling put the newest file at the bottom of my file list.

[foosel]

Hm, too bad. If toggling had always fixed it (temporarily) I at least would have had a lead to go on to but now I'm completely in the dark again.

It sucks that I can't reproduce this myself, that would make debugging way way easier.

I briefly thought that simply no sorting was being done when it breaks, but that's also not it, the order of files in the response body provided by @luke321 doesn't match the display order.

[luke321]

I just tried Microsoft EDGE and the order is correct.
So maybe the problem is Google Chrome specific?

[foosel]

I think I just found it. The issue appears to be caused by the comparator function not handling cases deterministically where one of the compared items doesn't have a date defined - as is the case for SD card files or folders.

I was just able to replicate the wrong sorting order in a minimal example based on the response data provided by @luke321, and adjusting the comparator function slightly fixed the sorting order. My current guess is that it could get fixed temporarily in some cases since sorting after e.g. name or size would sort the array in place and hence change the order in which parameters were supplied to the comparator function, which could lead to the correct outcome then depending on the data.

Very much theoretical right now, based on taking a long hard look at the code and the minimal example, but it at least makes sense!

[foosel]

Should be solved by the above commit. Already on maintenance, soon devel and to be released with 1.3.9