Changes between Initial Version and Version 1 of Ticket #17803, comment 4


Ignore:
Timestamp:
Jul 29, 2022, 6:06:39 PM (2 years ago)
Author:
leavengood

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #17803, comment 4

    initial v1  
    1 I'll test to reproduce but this is likely due to the caching as ttcoder deduced. If you have the actual file being replaced open then the node monitoring should update it. But I am fairly sure the caching code just loads the file and caches the bytes so that when you go to the next file with the arrow keys you don't have to wait for it to load. So if the file changes underneath it still has the old bytes. It also obviously uses the cache if you open a file that is already cached, which is this bug in question. But I think it would also is a bug if you replaced file2.png and then moving to it in the slideshow showed the old file (and I assume that is indeed what happens now.)
     1I'll test to reproduce but this is likely due to the caching as ttcoder deduced. If you have the actual file being replaced open then the node monitoring should update it. But I am fairly sure the caching code just loads the file and caches the bytes so that when you go to the next file with the arrow keys you don't have to wait for it to load. So if the file changes underneath it still has the old bytes. It also obviously uses the cache if you open a file that is already cached, which is this bug in question. But I think it also is a bug if you replaced file2.png and then moving to it in the slideshow showed the old file (and I assume that is indeed what happens now.)
    22
    33I think the solution will be to have the caching code do node monitoring and reload on change. Though that might get tricky and I feel like this code may already have some data races.