search

andrewrk / groovebasin

Music player server with a web-based user interface.
MIT License
1.87k stars 118 forks source link

slow initialization #302

Open roizcorp opened 10 years ago

roizcorp commented 10 years ago

the music library is long enough but later comes on the replay gain parsing which make the user experience even worse without proper notification to the user.

my suggestion is to make the replay gain feature as optional and on-demand feature

andrewrk commented 10 years ago

Can you explain in more detail how the replay gain scanning is unsatisfactory? What adverse effects are you observing?

roizcorp commented 10 years ago

hi,

I executed the groovebasin for the first time by demand (no service) the messages shown on the screen from what I understood, where: a. initializing (ports etc.) b. parsing my huge music library c. right after the long parsing I have noticed some messeges about fingerprinting my first song in the library then long waiting then I was able to play the music

BTW (perhaps should be posted in different bug) there is compatibility with MPD clients such as Android's MPDroid and Linux Gnome's GMPC

andrewrk commented 10 years ago

Related: #194

Yes please report any MPD client incompatibilities in separate issues.

kingcons commented 9 years ago

This may also be a concern for my 26,000+ song Amazon S3 FUSE filesystem usage. I'll be doing more testing of that shortly.

andrewrk commented 9 years ago

I'll be curious to see your results.

kingcons commented 9 years ago

The initial import took a while because it had to pull each song from S3 one at a time. Sending the library index downstream for a new client takes 2-3 seconds but I'm okay with that. It is 26,000 songs after all. App seems snappy enough afterwards so it works for my use case. Great work on groovebasin. :)

kingcons commented 9 years ago

Unfortunately, I need to amend my former statement. Sometimes I start the server and it takes 5-7 minutes to come up. Strace seems to indicate it is setting up filesystem watchers and/or going through the "folders" on S3. I haven't looked into this carefully. Can provide more info if needed. Not a big deal for me compared to CPU usage though, the program should only need to initialize once every few months or so. :)

andrewrk commented 9 years ago

Thanks for the update. I'll prioritize the CPU bug - I'm interested in seeing this S3 fuse idea succeed.

kevinf28 commented 9 years ago

If you restart the process and you have a large library (34k songs, samba share, gigabit network): Compacting the database and such consumes ~20 seconds see groovebasin.db/LOG (.db folder is 80-120MB). ~40 seconds when it was at 120MB After compacting another ~20 seconds, and groovebasin reports "listening on 0.0.0.0"

Not bad considering this is on a low power dual core HTPC.

It seems that fingerprinting / loudness detection is triggered by opening a web browser, and having particular songs queued. On demand seems to work.

That said, sometimes I open groovebasin without a browser, and it seems to continue where it left off parsing a particular album.

I have been off and on using groovebasin for days, I have no idea how much of my library has been parsed. Is this count one of the records in groovebasin.db/LOG eg: "Generated table #957: 368 keys, 1104031 bytes" ???

Is there a way to trigger a full library scan via command line? Ide love to precache this overnight, as parsing (understandably) uses 100% cpu load, while im using my machine. Simply leaving it playing through the autoDJ queue will take forever...

andrewrk commented 9 years ago

Is there a way to trigger a full library scan via command line?

No, but that's a good idea to add.