Thanks Michael. I was afraid of that. Looks like I was a bit stingy
when I selected the size of my root partition...
If you store the artwork files in a folder and configure the plugin to
use that folder, MAI won't have to re-download the files and will not
cache them in the regular
Thanks Michael. I was afraid of that. Looks like I was a bit stingy
when I selected the size of my root partition...Guess I'll have to see
if I can expand it. If not I have a great excuse to set up a new server
from scratch!
-Chris
I've got a situation where my cache.db seems to be blowing up to a much
larger size than usual. It's currently at 273MB. Looking at the log
file I am seeing the following warning message which I am thinking could
be related to the issue:
[17-02-07 03:01:12.7177] Slim::Music::Import::runImporter
slartibartfast wrote:
> Last night cache.db was 47MB. This morning it is 704MB and all I have
> done is listen to BBC Radio 2 via the BBC iplayer plugin. I am watching
> it rise as I write this 718MB now.
>
> Sent from my SM-G900F using Tapatalk
This seems to be an iPlayer plugin issue with
kidstypike wrote:
> Agree, using BBC iPlayer cache grew from 269 to 340MB in ~30mins.
Jusrt to repeat my hypothesis. HLS and DASH are chunked http so an
audio stream is made up of 3-6sec chunks of audio each sent as a
separate http request as compared to the older http stream which is sent
as
mherger wrote:
> > Last night cache.db was 47MB. This morning it is 704MB and all I have
> > done is listen to BBC Radio 2 via the BBC iplayer plugin. I am
> watching
> > it rise as I write this 718MB now.
>
> Now you could uninstall that plugin, wipe the cache, and try again. If
> behaviour
Last night cache.db was 47MB. This morning it is 704MB and all I have
done is listen to BBC Radio 2 via the BBC iplayer plugin. I am watching
it rise as I write this 718MB now.
Now you could uninstall that plugin, wipe the cache, and try again. If
behaviour is back to normal, then you know the
mherger wrote:
> As I said: this heavily depends on your use of plugins and internet
> services. Some information about them might help to understand the
> issue.
>
> Michael
No Internet Streams - running 7.9.0 - 1472937447
Code:
du -h
No I didn't check the Server log. My cache.db is 47MB now, I will keep
an eye on it over time. Even 47MB seems high compared to 15MB.
As I said: this heavily depends on your use of plugins and internet
services. Some information about them might help to understand the issue.
--
Michael
I know this is an old thread but somehow I ended up with a cache.db file
of over 1GB and a cache.db-wal file of over 500MB running the latest LMS
7.9. I thought those days were long gone.
The size of cache.db doesn't depend on artwork (there's artwork.db and
imageproxy.db for that). It's used
Hm, then I'd expect it to not grow beyond 500-600MB
---
learn more about iPeng, the iPhone and iPad remote for the Squeezebox
and
Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
at penguinlovesmusic.com
*New: iPeng 9, the Universal App for iPhone, iPad and Apple Watch*
pippin wrote:
> Not at all. If your library is large enough...
> IIRC some newer LMS versions actually even put the full-scale artwork
> into the cache dbs so it can easily grow that big.
> Which control Apps do you use?
> iPeng now pretty much tries to optimize cache space use (except for iPad
Not at all. If your library is large enough...
IIRC some newer LMS versions actually even put the full-scale artwork
into the cache dbs so it can easily grow that big.
Which control Apps do you use?
iPeng now pretty much tries to optimize cache space use (except for iPad
2 iPeng 9 now uses the
mherger wrote:
> > Well after the restart cache.db is 185K and artwork.db just under
> 27MB.
> > So that's fixed it, thanks very much. I guess I have to keep an eye on
> > these files.
>
> As others mentioned you might want to update to 7.7.3 or later, as there
>
> was a bug in earlier caching
14 matches
Mail list logo
