Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23
  1. #11
    Member
    Join Date
    Sep 2017
    Location
    ┼kersberga, Sweden
    Posts
    84
    Quote Originally Posted by THildebrandt View Post
    At the moment the server runs, scanning without problems... the only 'problem' is that for some reason sqllite db are created on the old AND the new cache dir...

    Any ideas why this happens??? Obviously i would prefer that only the new cachedir is used...

    Thx...
    Looking in the startscript /etc/init.d/logitechmediaserver where the variables in /etc/default/logitechmediaserver are used to build the commandline, I would suggest that instead of
    Code:
    SLIMOPTIONS=""
    CACHEDIR=/new location/logitechmediaserver/cache
    you could try
    Code:
    SLIMOPTIONS="--cachedir /new location/logitechmediaserver/cache"
    instead.

    Maybe the "CACHEDIR" variable from your /etc/default/logitechmediaserver is sourced before the variable is set in the startup-script?
    At least the "SLIMOPTIONS" variable is only used when building the commandline.

    Hope this helps (I haven't tested it myself).
    2 Touch, 2 Picoreplayer 5.0.0 on RaspBerry 3B, 1 RasbBerry Zero running Raspian and Squeezelite 1.8
    LMS latest nightly on Ubuntu 18.04.3 on Intel Core2 Duo E4500 @ 2.20GHz, 2GB
    All wired

  2. #12
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    901
    Quote Originally Posted by THildebrandt View Post
    At the moment the server runs, scanning without problems... the only 'problem' is that for some reason sqllite db are created on the old AND the new cache dir...
    Depending on which music importers are used, LMS either uses it's internal scanner, or runs scanner.pl as an external process.
    Maybe one of the two uses the old location, the other the new. Why this happens, I have no clue.
    Things you could try:
    - check if any entry in server.prefs still references the old location
    - increase the logging levels of scan, scan.scanner and server in Settings>Advanced>Logging and check scanner.log / sever.log (the ones you posted don't show anything suspicious)
    - try moving the cache to a non-encrypted location to make sure this doesn't somehow interfere (btw, if you really need encryption, make sure it's hardware-accelerated, otherwise it may severely degrade performance)

    btw, is there really a difference in the file names (Persist.db vs. persist.db) ?

  3. #13
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    901
    Quote Originally Posted by BosseJ View Post
    you could try
    Code:
    SLIMOPTIONS="--cachedir /new location/logitechmediaserver/cache"
    I'd advise against this - you'll end up with two "--cachedir" arguments (since the script already passes --cachedir $CACHEDIR)

    Maybe the "CACHEDIR" variable from your /etc/default/logitechmediaserver is sourced before the variable is set in the startup-script?
    The variables are set to defaults in the script first, then /etc/default/logitechmediaserver is sourced, overwriting the default values.

  4. #14
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,279

    Debian / OMV installation - location ofcache...

    > Maybe one of the two uses the old location, the other the new. Why this
    > happens, I have no clue.


    There's another pref "librarycachedir" which is being generated upon
    first start (IIRC). That's what's being used for the library files. You
    might need to reset its value before restarting LMS with the new
    cachedir value.

    --

    Michael

  5. #15
    Junior Member
    Join Date
    Aug 2019
    Posts
    13
    Quote Originally Posted by Roland0 View Post
    Depending on which music importers are used, LMS either uses it's internal scanner, or runs scanner.pl as an external process.
    Maybe one of the two uses the old location, the other the new. Why this happens, I have no clue.
    Things you could try:
    - check if any entry in server.prefs still references the old location
    - increase the logging levels of scan, scan.scanner and server in Settings>Advanced>Logging and check scanner.log / sever.log (the ones you posted don't show anything suspicious)
    - try moving the cache to a non-encrypted location to make sure this doesn't somehow interfere (btw, if you really need encryption, make sure it's hardware-accelerated, otherwise it may severely degrade performance)

    btw, is there really a difference in the file names (Persist.db vs. persist.db) ?
    1st: no - my error, persist both places with lower case p...
    2nd: server.pref contains this line referencing the old cache location: dbsource: dbi:SQLite:dbname=/var/lib/squeezeboxserver/cache/library.db

    2nd point may very well be the culprit... but how to change??? changing this line to reference the new cache dir does not end well...

  6. #16
    Junior Member
    Join Date
    Aug 2019
    Posts
    13
    Quote Originally Posted by mherger View Post
    > Maybe one of the two uses the old location, the other the new. Why this
    > happens, I have no clue.


    There's another pref "librarycachedir" which is being generated upon
    first start (IIRC). That's what's being used for the library files. You
    might need to reset its value before restarting LMS with the new
    cachedir value.

    --

    Michael
    How do i reset this??

  7. #17
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    901
    Quote Originally Posted by THildebrandt View Post
    1st: no - my error, persist both places with lower case p...
    2nd: server.pref contains this line referencing the old cache location: dbsource: dbi:SQLite:dbname=/var/lib/squeezeboxserver/cache/library.db

    2nd point may very well be the culprit... but how to change??? changing this line to reference the new cache dir does not end well...
    keep CACHEDIR in /etc/default/logitechmediaserver
    shut down LMS
    remove all server.prefs file(s) (check old and new locations, or even run "sudo find / -name server.prefs" on the file system)
    delete all files in your old cache location
    start LMS

  8. #18
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,279

    Debian / OMV installation - location ofcache...

    >> There's another pref "librarycachedir" which is being generated upon
    >> first start (IIRC). That's what's being used for the library files. You

    >
    > How do i reset this??


    Edit server.prefs to make it point to where you want it to be. Then
    delete the dbsource line you quoted earlier.

    --

    Michael

  9. #19
    Junior Member
    Join Date
    Aug 2019
    Posts
    13
    Checked server.prefs for 'librarycachedir' and it was already pointin to the new cahce dir.

    I then:
    stopped lms service
    erased the entry in server.prefs: dbsource: dbi:SQLite:dbname=/var/lib/squeezeboxserver/cache/library.db
    and changed
    Code:
    SLIMOPTIONS=""
    CACHEDIR=/new location/logitechmediaserver/cache
    to
    Code:
    SLIMOPTIONS="--cachedir /new location/logitechmediaserver/cache"
    restarted lms service and initiated scan - with succes: old library.db & persist.db timecode was unchanged through the music library scan while the files in the new cachedir were updated.

    deleted old cache dir completely, stopped & started LMS and initiated new scan - with succes again!!!

    mherger & Roland0 - thx for helping!!!

  10. #20
    Member
    Join Date
    Sep 2017
    Location
    ┼kersberga, Sweden
    Posts
    84
    Quote Originally Posted by THildebrandt View Post
    Checked server.prefs for 'librarycachedir' and it was already pointin to the new cahce dir.

    I then:
    stopped lms service
    erased the entry in server.prefs: dbsource: dbi:SQLite:dbname=/var/lib/squeezeboxserver/cache/library.db
    and changed
    Code:
    SLIMOPTIONS=""
    CACHEDIR=/new location/logitechmediaserver/cache
    to
    Code:
    SLIMOPTIONS="--cachedir /new location/logitechmediaserver/cache"
    restarted lms service and initiated scan - with succes: old library.db & persist.db timecode was unchanged through the music library scan while the files in the new cachedir were updated.

    deleted old cache dir completely, stopped & started LMS and initiated new scan - with succes again!!!

    mherger & Roland0 - thx for helping!!!
    Roland0 advised (correctly) against setting the SLIMOPTIONS variable to "--cachedir /new location/logitechmediaserver/cache". See item #13 in this thread.
    It may work now but you have a start command that has two "--cachedir" directives and it may cause problems in some future upgrade.

    I'm sorry for my bad advice. I should have either corrected my post or commented on Rolands reply to make it clear that I understood and accepted his explanation.
    2 Touch, 2 Picoreplayer 5.0.0 on RaspBerry 3B, 1 RasbBerry Zero running Raspian and Squeezelite 1.8
    LMS latest nightly on Ubuntu 18.04.3 on Intel Core2 Duo E4500 @ 2.20GHz, 2GB
    All wired

Tags for this Thread

Posting Permissions

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