Hello again Michael.
I'm back now and said I'd report back.
With the Database Memory Config set to High the database optimisation
completed in a pretty quick 5 minutes...
...but pre-caching the artwork took nearly 2 hours.
Not a problem as at least the whole process completed but
I have been setting my Pi to normal memory use since I started running
MusicIP and had memory issues. Will this change allow me to use High
again?
Depends on how it failed before...
--
Michael
___
Squeezecenter mailing list
Thanks Michael.
I'm off travelling shortly so I'll update to your new build on my return
(mid-Sept) and report back then.
Asset is the dBpoweramp DLNA server.
PSH's Profile:
mherger wrote:
> I just pushed a change which would hopefully address your issue. Could
> you please update to the next build (due out in about an hour),
> re-enable high memory usage, and try again?
>
> > Asset
>
> What's Asset?
>
> --
>
> MichaelI have been setting my Pi to normal
I just pushed a change which would hopefully address your issue. Could
you please update to the next build (due out in about an hour),
re-enable high memory usage, and try again?
Asset
What's Asset?
--
Michael
___
Squeezecenter mailing list
Yup - apart from squeezebox it is also running:
Asset
Minim
Twonky
JRiver
PSH's Profile: http://forums.slimdevices.com/member.php?userid=68392
View this thread: http://forums.slimdevices.com/showthread.php?t=109093
25558Hope this helps
Thanks, it does. I wanted to make sure that the code I'm about to put in
place would have caught your case. From that screenshot it looks like
you were really low on memory overall... There must be running quite a
bit more than just LMS?
--
Michael
25558Hope this helps
+---+
|Filename: meminfo.png |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=25558|
Using ls -l filename, I get the following:
library.db = 324,410,368
library.db-shm = 32,768
library.db-wal = 0
Thanks. I think I'll have to work on the optimization step some more.
Could you please post the output of "cat /proc/meminfo"?
--
Michael
Using ls -l filename, I get the following:
library.db = 324,410,368
library.db-shm = 32,768
library.db-wal = 0
PSH's Profile: http://forums.slimdevices.com/member.php?userid=68392
View this thread:
4427 albums
76618 songs
2636 artists
It's a shame this wouldn't work with the highmem parameter enabled, as
the overall scan time should be considerably smaller.
How large are the library.* files in the cache folder?
--
Michael
___
Squeezecenter
4427 albums
76618 songs
2636 artists
PSH's Profile: http://forums.slimdevices.com/member.php?userid=68392
View this thread: http://forums.slimdevices.com/showthread.php?t=109093
The Raspberry Pi is now executing the database optimization when set to
Normal.
How large is your collection?
--
Michael
___
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/squeezecenter
This thread was very useful to me in sorting out a problem I had with
non-optimization on a Raspberry Pi.
For the record I have installed LMS on a Raspberry Pi and a Pi Zero
(wireless).
LMS works well on both but the database optimization failed on the
Raspberry Pi. Surprisingly it was OK on
Bronx wrote:
> Frankly, I do not need a function to export or import ratings. I'm
> confident I can do this with a SQLITE browser and lots of manual labor
> when needed. But I don't need ratings anywhere else than on LMS. I can
> export playlists to mobile players based on ratings anytime.
>
>
DJanGo wrote:
> Is this really a big missing point?
>
> eg someone has 2 different apps that handle ratings. If these ratings
> arent added to the Tag of the track, you soon end up with two different
> ratings for a single track.
> LMS does handle ratings in the track - so its just a matter of
mherger wrote:
> I guess that's the big missing point in LMS core: it doesn't really deal
>
> with importing/sharing ratings with other applications?
>
> --
>
> Michael
Is this really a big missing point?
eg someone has 2 different apps that handle ratings. If these ratings
arent added to
- LMS will never overwrite the values in tracks_persistent table
(unless (maybe?) a file contains a rating tag - not sure about this
case)
That's too general to be true: it does keep track of playcounts, last
time played etc. There's code to set the rating, too. But it's probably
not
Bronx wrote:
> According to Wiki, Tracks_persistent - is the table where Squeezebox
> Server/Logitech Media Server stores its rating information. When
> changing a rating in TrackStat it will always also write the information
> to this table, but the tracks_persistent table will generally be
>
Roland0 wrote:
> Ratings (and play counts) are native to LMS, so if that's all you need
> (and file paths haven't changed), there's no need to import - the
> existing persist.db contains these, and they are not overwritten by a
> re-scan. TrackStat synchronizes it's own data with LMS' on
Bronx wrote:
>
> Main problem: I've had to replace the external hard drives several
> times, be it because of full disk or defects. I also have 3 backup
> generations. It is extremely cumbersome to restore reviews with
> Trackstat Restore. The import always takes several days. There is also
>
mherger wrote:
> May I ask how you use the TrackStat plugin? Which of its features are
> the most important? And where do the performance issues kick in?
Hi Michael
I periodically receive links with new albums from a provider that serves
several German/Swiss/Austrian download platforms with
Bronx wrote:
> The only thing that bothers me about LMS is the fact that no rating
> system is built into the core of LMS (as a music editor, reviews of
> tracks are the center of my use of LMS). Here I see a great need. The
> Trackstat plugin greatly inhibits the performance of larger
There are new builds out which should work for you, too. It changes the
behaviour in that it does a "sanity" check (not really sane, but better
than nothing) about the db file's size. If it's larger than 1GB, then it
wouldn't store it in memory, but use disk instead. Even if dbhighmem was
Now that's interesting. How do scan times compare? Because I thought
that "max" would greatly improve scan times for what I considered large
collections (>50k :-)).
The good news is that the analyse part seems to run fine (and that's the
important part!). Only the vacuum is causing problems. I
mherger wrote:
> I'd even recommend to delete it and artwork.db (NOT persist.db) - if you
> can afford the time to re-build it. Depending on how long you've been
> running LMS, and how you did upgrade to 7.9 it might miss some
> configuration parameters I implemented in 7.9 which would only be
Bronx wrote:
> Would you recommend me to "manually" vacuum library.db? If so, could you
> please instruct me how to do that within sqlite?
I'd even recommend to delete it and artwork.db (NOT persist.db) - if you
can afford the time to re-build it. Depending on how long you've been
running LMS,
Now THAT's a massive collection...
The scanner is reporting disk I/O and "out of memory" issues. Sounds
like either the partition used for temporary storage is in running low
on free space or something. Could you please monitor memory as well as
disk usage while you are running a scan? In
28 matches
Mail list logo
