Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 6 of 6
  1. #1
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,262

    high CPU on a Pi3B+

    I know I should know better but ... I recently noticed that my LMS 7.9.2 - 1572530107 on Pi 3B+ was slow. It seems that in average, the squeezeserver process is eating 80+% of CPU, even when doing nothing. I can do the brute force option and re-install, but any better option to investigate what can have such impact?
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,352

    high CPU on a Pi3B+

    > I know I should know better but ... I recently noticed that my LMS 7.9.2
    > - 1572530107 on Pi 3B+ was slow. It seems that in average, the
    > squeezeserver process is eating 80+% of CPU, even when doing nothing. I
    > can do the brute force option and re-install, but any better option to
    > investigate what can have such impact?


    Does the behaviour change if you restart LMS? What OS are you using? I
    bet you got quite a few plugins installed :-). You could try to narrow
    down whether it's one of them.

    Or are you using AutoRescan?

    --

    Michael

  3. #3
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,262
    Quote Originally Posted by mherger View Post
    > I know I should know better but ... I recently noticed that my LMS 7.9.2
    > - 1572530107 on Pi 3B+ was slow. It seems that in average, the
    > squeezeserver process is eating 80+% of CPU, even when doing nothing. I
    > can do the brute force option and re-install, but any better option to
    > investigate what can have such impact?


    Does the behaviour change if you restart LMS? What OS are you using? I
    bet you got quite a few plugins installed :-). You could try to narrow
    down whether it's one of them.

    Or are you using AutoRescan?

    --

    Michael
    It's a Stretch with 4.14.98. It does not change with restart of LMS or reboot of the Pi. I don't think it's autorescan b/c it's has been doing that got like a wekk now. I'll clear the cache dir and then go the plugin route ...
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  4. #4
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,262
    hmmm ... found the guilty plugin and it was one of mine, of course . LMS was constantly asking for metadata of a track that was not and could not be cached. Would you happen to know, when getMetadataFor is called, what is the minimum infoset that will decide LMS to not continue asking for metadata? Is this artist, album, duration, title? Otherwise I'll look at the code
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  5. #5
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,352

    high CPU on a Pi3B+

    > hmmm ... found the guilty plugin and it was one of mine, of course .
    > LMS was constantly asking for metadata of a track that was not and could
    > not be cached. Would you happen to know, when getMetadataFor is called,
    > what is the minimum infoset that will decide LMS to not continue asking
    > for metadata? Is this artist, album, duration, title? Otherwise I'll
    > look at the code


    The status query would certainly use that function to get track
    information. Probably display code?

    I usually do cache in getMetadataFor too, in particular when dealing
    with remote tracks. Would yours have been an expensive call?

    If in doubt (and if you don't fear the excessive logging), you could
    always add a logBacktrace() statement to getMetadataFor() to see where
    the calls are coming from. I'm not sure whether the callers do implement
    any kind of caching.

    --

    Michael

  6. #6
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,262

    high CPU on a Pi3B+

    Quote Originally Posted by mherger View Post
    > hmmm ... found the guilty plugin and it was one of mine, of course .
    > LMS was constantly asking for metadata of a track that was not and could
    > not be cached. Would you happen to know, when getMetadataFor is called,
    > what is the minimum infoset that will decide LMS to not continue asking
    > for metadata? Is this artist, album, duration, title? Otherwise I'll
    > look at the code


    The status query would certainly use that function to get track
    information. Probably display code?

    I usually do cache in getMetadataFor too, in particular when dealing
    with remote tracks. Would yours have been an expensive call?

    If in doubt (and if you don't fear the excessive logging), you could
    always add a logBacktrace() statement to getMetadataFor() to see where
    the calls are coming from. I'm not sure whether the callers do implement
    any kind of caching.

    --

    Michael
    Yes, they were expensive calls that normally are cached upon resolution but there, for some reason, the request for metadata was for an old remote track that was not available anymore online, so could not be resolved (so could not be cached). I initially thought that the callers of getMetadataFor would stop when they get what they want, but I'm wrong. I need, to prevent such case to happens again, to create and cache a "fake" metadata when the url is not available anymore online
    Last edited by philippe_44; 2019-11-21 at 00:13.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •