Cloud storage folders with lots of videos

[superehots]

Hi again.

I tested the cloud storage update a few days ago. It works fine on the pikpak storage I mounted with rclone. It's a really cool update.
I understood that it doesn't work as a folder with a large number of videos.

To test this, I tried to access the folder where I put 50 videos.
As you say, it goes to infinite loading but after a while on PC, when I stop and replay the passthorough server, the list appears. The video plays well too. (My description is all based on Heresphere)

From then on, even if I restart the program or Heresphere, it will be connected without loading.
I'd like you to check about this.

Another thing is that the time index is so detailed that I rarely use it because of the hassle of having to keep going into subfolders. I think minutes should be enough.

The other thing is, of course you know, the whole body gets masked in certain situations. Maybe this is the limitation of the model used and it's difficult, but hopefully it'll work out one day.

I know the original site, but I can't sign up, so please understand that I leave feedback here.

Your work is worthwhile.

[zerochocobo]

I just saw this issue; I've been working on another software development project recently.

1. The problem you described involves folder caching, which occurs in two locations: one is the player's DLNA cache (based on the DLNA objectid), and the other is our software's internal cache, located in the library_index.sqlite file within the runtime_cache directory. The cache is only updated when there are changes within the directory. Some players cache individual video information, such as Skybox, and I can't clear this except by deleting and reinstalling the software. I'm unsure which cache location you're experiencing. If changes to your directory content still prevent updates, I might need to add a feature to manually manage the library_index.sqlite file. Otherwise, manually refreshing within the software won't update the cache for this file. You can try adding or deleting a file in the folder to see if it updates.

2. This is a design issue with the time index. The main reason for this is to address the original time being too coarse. The directory depth was increased during the design phase. This was to reduce the number of entries in the last level (reducing the number of original video requests the player needs for screenshots) and to cater to impatient users who don't want to wait even tens of seconds. When using the player, switching between levels takes far less time than waiting tens of seconds, hence the design choice. I spent two days trying to implement a draggable MP4 player to completely solve this problem, but unfortunately, I failed. This is because I need to know the size and other information of all video segments when the user requests the file to stitch together the moov header. Trying TS or fMP4 formats also failed. Having reached a dead end, this is the best I could do. The design also needs to limit the number of directories or files under a single level to around 10 to reduce excessive scrolling.

3. The issue of passthrough matting. The real-time model uses RVM, which is currently the most suitable for real-time processing. Better results might be achieved in SAM3's offline mode, but even that isn't guaranteed to produce the desired effect, especially under VR distortion. Currently, it's largely a matter of luck.