Caching with backward seeking is not optimized

Describe the bug
When seeking backward more cache is reloaded then it needs to be. Probably related to LRU caching method which is not optimal for dealing with streams.

Test file

Steps to reproduce the behaviour:

Test file is
/ipfs/QmaWQgBv77QEPRgxzx3KrW3Y5oyzpbgGTpWdi9xh1PTRHS - its 178MB mp3 1h14m16s long

audio file from dead world radio episode 27 -> https://pin.ski/3pXsqht or https://crustwebsites.net/ipfs/Qmcp5Tu1Zg6sHj8JncRzXYFosMhuTtVn2f9WiUEzEHAJmP?filename=027

You need to access test file through some IPFS gateway prepend gateway URL to IPFS address. Examples some gateways:
https://crustwebsites.net/ipfs/QmaWQgBv77QEPRgxzx3KrW3Y5oyzpbgGTpWdi9xh1PTRHS or https://gw.crustapps.net/ipfs/QmaWQgBv77QEPRgxzx3KrW3Y5oyzpbgGTpWdi9xh1PTRHS or
http://bafybeifuzqxrrvg7sm2feb2jlxlu4tat5gxcozrqdd3avalqwpeql7f4be.ipfs.cf-ipfs.com

Its not critical to get the same file used for test probably streaming any other mp3 with similar size and duration can be used instead.

Problem

1. we play the file from start and it will download and cache 43minutes. Indicated by line on screen. Cache size reported on console to be 150M.

2. Then we click and play at time 35 minutes. Cache will shift and will be from 16m to 1h14m. So far so good.

3. Then we click on 6 minute. Correct optimal behaviour will be to cache 10 minutes from 6m to 16m and free last 10 minutes because we already have rest downloaded.

4. This is not what is happening. mpv will load data at 6 minutes and moving forward and remove oldest blocks from cache which are at 16 minute. This will create moving hole and after we reach 16th minute when loading cache moving forward we would need to load data that were previously freed,

No source file or test is named. Reproduce the behavior with the provided large MP3 through an IPFS gateway, then trace the cache and LRU handling during the described seeks from the start to 35 minutes and back to 6 minutes. Done means backward seeking avoids reloading data that is still available and preserves the expected cached range.