Closed nis65 closed 1 week ago
Thanks for the detailed logs. Unfortunately for you though, working with large playlists is simply not something RompR can do. Every track in that playlist is being looked up in the database and the issue is almost certainly that the request to retrieve it is timing out. There is no fix for this I'm afraid, that's just how it works.
Wouldn't it be possible (as workaround) to simply skip the database lookup to create the playlist? So maybe a configuration option that says:
ugly_but_fast_playlist=true
and in this case it would work identical to my test setup with the database removed temporarily... As I wrote - I am not missing anything in the playlist when there is no database...
Or decouple the database lookup from the gui response times like the fetching of album art?
You would be missing functionality, but you haven't noticed it. There are features that don't work without the lookup, and reworking it would break more things.
Ok, thanks for your time. I'll see what I can do to help myself :-) Closing.
Hi
First thanks for that very nice web client. I have integrated RompR into my rompr branch for my multiroom setup.
My issue:
after reading in my collection (takes quite some time, but completes successfully), I almost never get to see the current playlist with over 600 entries. When I shorten the list to 174 tracks (total 13h30m) and do a reload, it takes 22 seconds until the list is displayed. As I usually work with that long playlists, this is really a showstopper for me.
I rose the log level to 7 (DEBUG) to see about every other seconds a DEBUG message about an album art of one of the albums on my playlist. But this was just a red herring...
when I move away temporarily the database file (
rompr/prefs/collection.sq3
), the current playlist is displayed almost instantaneously, even with the album art. This playlist has currently about 600 items, a few of them are radio stations. Of course I cannot browse the database or do anything else useful that needs the database.So: I am sure that one or more database queries slow down the build up of the playlist considerabely. However, after setting the log level to 8 (CORE), I see a lot of SQL statements but I am overwhelmed and fail to track to down that "bad" statement that kills the display of the playlist. What information is collected from the database when the playlist is shown? I don't seem to miss anything in the playlist when the DB is empty.
Any ideas how to proceed?
I don't think this is related, but
rompr
has no access to the files of the collection, they are visible viampd
only. This is because a)rompr
is running in a container and b) even if this container runs on the raspi that runsrompr
, the collection is "mounted" formpd
via ansmb
url:Some more stats:
Debug Information