-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow initial start with huge collection #264
Comments
hm yeah we could create an index or something |
If it really a few minutes? Or seconds? |
Nope, I'm not using snap. I'm using the appimage. First startup took around 7 minutes and it showed a message I've got 29k songs and if I want to save the cache. But after that the GDM broke and I needed to reboot. I'm trying to start it again and it's rebuilding indexes again. Here's the screen recording I've made until the crash. Screencast.from.2023-11-17.00-47-08.webmI'll try to save the cache again once it's built. The crash may be due to recent update on of kernel modules and without reboot (I hope). I'll report back the results if the cache saving passes. I'll try to run the flutter project to have some logging if the crash happens again. |
OK, now closing is almost instant. Here's the startup screen recording: Screencast.from.2023-11-17.01-05-58.webm |
Here's the app profile startup. The first item in dart debugger says it took 11s. I think you can import it in your profiler or something. It may help. |
Thank you for the detailed report! I'll move the index building and index loading onto a second CPU threat (called isolate in dart) to not block the UI |
@eboye okay :) check main again, I think this is now good for both extremes: very big library and cache wanted and people with small library or people wo dont use the local audio feature at all (and only use radio and podcast feature) |
Well, it's kinda worse then the last version. It acts like it's rebuilding every time even though it's set to use caching. Screencast.from.2023-11-18.01-25-04.webm |
Damn. Okay I think I need to rethink this totally Oop approach to audio files and their metadata. I think the problem might be the images in the mp3s |
okay @eboye I think now it is better :) I made a mistake Screencast.from.2023-11-18.11-42-53.webmIn my ~2k audio collection this cache slows down the start if this finall works better for your huge library then I will set the threshold to ask for the cache maybe to 5k |
Great! Not ideal, but I think this is much more usable :) Screencast.from.2023-11-18.12-31-39.webmI think we can close this issue. I have some experience with flutter (but mobile only), so I'll see if I can find some tweaks here and there to speed up the process. If I do, I'll make PRs :) Thanks! |
Thanks! This was after loading the cache? |
Yes, with cache loaded. Well, native ones are much much faster (C, Rust, Python...), electron is mixed bag. Strawberry and Clementine are extremely fast for example. But the UI is garbage IMHO 😀 OK, but I really like the UI on this one, so I'll stick with it for now. |
@eboye hey again. I've made another mistake and accidently created the cache twice... sooooo it should in theory be 2x fast for you now :) if you have time would appreciate if you re-check main / snap from edge |
Will do. I'm using an appimage that I build myself 😁 I'll report back |
Initial start is instant. First start never finished indexing or what. Is it parsing the index that long or is it reindexing?When it finished, closing was instant. |
Sounds good except that the loading of the local audio takes again same time. If I understand this correctly? |
Yup, when the index is saved, loaded from cache, it takes some time, maybe not as indexing, but still it's slow to show something. I'll record the video if you need. I expect it to be under 10-15 seconds. |
video would be nice Make sure to delete the config folder of musicpod first |
Hmm, I'm debugging now and it seems that ~/.config/musicpod is recreating when the app is started. But deleting it doesn't delete the index. In ~/.cache/images are only images, there is no index files. I look for MusicPod folder, but it doesn't seem to be in nor config nor cache. I'm not using snap, so there is no ~/.snap folder. |
this seems to be different for app images then |
hey @eboye I've cleaned up a lot of bad code. Especially today with localaudios could bring some improvements. |
Yeah.. it's sadly not possible to exclude the memory images while reading the metadata. |
hey @eboye |
I'm not sure if this is the same bug, and don't want to create a duplicate if so, but for me, Musicpod simply shows a big, flashing, music icon: It never moves past this point, and running it from the CLI doesn't give useful output, so I can't tell what's actually happening. I'd love to use it to replace Rhythmbox, but I can't even get into the interface. Any idea what could be causing this? My library is pretty huge, btw, but I never even got to the point where I could configure the application, so I can't tell it what to load or not. |
Update: So, I got frustrated with waiting, and decided to try renaming my music and video folders temporarily. This worked for getting into Musicpod, but now it's still taking forever to actually load anything. A more familiar workflow, as happens in many similar apps (though, frankly, not all do this - and I wish they would) - is to have the application load these folders asynchronously. In other words, it allows the user to view and play files while it's adding the remainder. Now, I don't know if this is a greater technical challenge, but it would at least help with the long wait times. EDIT: I'm using the latest version in the edge channel. EDIT2: If you try this and then restore the correct folder names, it hangs again, so this is NOT a workaround. |
I've got a very big collection of music. When closing and starting the app it hangs for few minutes like this:
Is there a way it can load items from cache and sync in background?
This is the folder I'm using as collection in MusicPod
~45.000 files
The text was updated successfully, but these errors were encountered: