Restore Squeezebox Server settings doesn't work

Max2Play Home 2016 (en) Forums Max2Play as Squeezebox (Player / Server) Restore Squeezebox Server settings doesn't work

This topic contains 18 replies, has 3 voices, and was last updated by  Heiner Moderator 2 years, 4 months ago.

Viewing 19 posts - 1 through 19 (of 19 total)
  • 15. April 2018 at 14:02 #35191

    Restoring squeezebox server settings just won’t work. I’m updating from Jessie Lite to Stretch and would love not to have to redo all configurations. Anybody did this successfully? If yes, how?

    max2play doesn’t display any error messages when uploading the configuration file. It doesn’t display a success message as well. I upload – no status message – nothing happens.

    23. April 2018 at 11:56 #35272

    Hi cramcram,

    Did you update from an existing image or burn a new Stretch Image? How did you integrate the file into the new system: USB mount, network mount or Samba? I will try to recreate the issue here.

    3. Mai 2018 at 20:51 #35517

    I burned a new Stretch image. Beforehand I had exported the settings from my working and configured Jessie Lite image. Files are integrated via Samba Share.

    14. Mai 2018 at 15:28 #35675

    Hi cramcram,

    The back-up should work completely from your PC via web interface and without SambaShare. Just download the file from the old Max2Play and upload it via web interface to the new one. I tested this here without a problem, it even migrated the Spotify login from Spotty.

    You should get these infos after clicking restore (having selected your file from Explorer or other file manager on PC):
    Trying to Restore Squeezebox Server Settings…
    File Uploaded
    File move successful

    Settings successfully restored! Please restart Squeezebox Server now.

    17. Mai 2018 at 10:30 #35734

    Does not work for me, too.
    I did exactly what Heiner said: Download via Web from Jessie and upload via web to Stretch. No samba shares.
    Result:
    Trying to Restore Squeezebox Server Settings…
    Upload NOT successful!

    Tried both, Squeezebox server running and stopped.
    The tar file is 55 MB. Maybe it takes too long to upload via WLAN?

    22. Mai 2018 at 14:37 #35802

    Hi Mike,

    I tried again with your setup, my file was also ca. 55 mb. Jessie image with configured LMS to Stretch image with freshly installed LMS. The Jessie version had an older install of LMS 7.9.0 while the Stretch had LMS 7.9.1.

    Unfortunately, I could not reproduce your error. With LMS running, I again got:
    Trying to Restore Squeezebox Server Settings…
    File Uploaded
    File move successful

    Settings successfully restored! Please restart Squeezebox Server now.

    Please share your debug info from the Squeezebox Server menu.

    Since I have not heard back from cramcram, I assume he is yet to try using a normal browser instead of Samba. Please let me know if you can reproduce Mike’s error.

    If so, please share your debug info log.

    22. Mai 2018 at 15:16 #35810

    I didn’t try again. I finally just reconfigured everything in LMS manually. Samba ist not the issue, I uploaded normally via web browser in the m2p interface. The upload itsself was useful, however the settings were just not applied – no configuration change. There was no error message.

    22. Mai 2018 at 15:27 #35812

    Hi Heiner,

    thanks for trying. I just did it again without success (after rebooting the server). Debug shows nothing:

    2018-05-22 15:12:38 squeezeboxserver_safe stopped.
    2018-05-22 15:13:14 squeezeboxserver_safe started.
     
    #### PERL VERSION ####
    v5.24.1

    Could it be a problem with disk space? System looks like this:

    #### FILESYSTEM ####
    Filesystem     1K-blocks     Used Available Use% Mounted on
    /dev/root        3536880  2782288    581856  83% /
    devtmpfs          495484        0    495484   0% /dev
    tmpfs             500092        0    500092   0% /dev/shm
    tmpfs             500092        0    500092   0% /sys/fs/cgroup
    tmpfs             500092    52476    447616  11% /run
    tmpfs               5120        4      5116   1% /run/lock
    /dev/mmcblk0p1     42136    22164     19973  53% /boot
    /dev/sdb1       62500560 60312696   2187864  97% /media/usb1
    /dev/sdd1        7798864   688528   7110336   9% /media/usb2
    #### LOAD AVERAGE ####
    0.21 0.10 0.09 1/127 4354
    #### KERNEL ####
    Linux max2play 4.14.39-v7+ #1112 SMP Sat May 5 12:01:33 BST 2018 armv7l GNU/Linux
    #### LINUX-VERSION ####
    Distributor ID:	Raspbian
    Description:	Raspbian GNU/Linux 9.3 (stretch)
    Release:	9.3
    Codename:	stretch
    • This reply was modified 2 years, 5 months ago by  Mike.
    24. Mai 2018 at 9:42 #35846

    Hi Mike,

    Your disk space is indeed very crowded for Max2Play standards. What size SD card are you using?

    24. Mai 2018 at 14:38 #35860

    I use a 4 GB card. The tar-file is now 77 MB, but root partition still has ~500 MB left. So it should work in my opinion, even if it needs twice the space for untaring.
    Maybe I should get a larger card for testing.

    24. Mai 2018 at 14:43 #35861

    It is still odd, that Max2Play occupies over 80 percent of the card. If you are using a Stretch image, your partition should have automatically been resized, same with newer Jessie images. E.g. in our 8 GB cards, Max2Play occupies ca. 32 percent.

    24. Mai 2018 at 14:58 #35862

    I think it has expanded. The partition list shows ~3.5 GB for root. Is this not enough? Rest may be used for tmp?
    I don’t know enough about Linux to really check this.
    If you have 32% used on 8 GB, it would be ~65% on a 4 GB card. With 83% some 500-800 MB are „lost“. How can I check proper expansion?

    24. Mai 2018 at 16:35 #35863

    Hi Mike,

    You’re right, if you installed LMS and some other plugins, this might amount to this much occupied space and the remainder should indeed still be enough for the backup to work. Could you try taking the original LMS‘ file again to rule out the file as a source of error?

    Also, could you detail your current setup including active plugins and application so I can rule out any interferences?

    24. Mai 2018 at 17:50 #35866

    Hi Heiner,

    same error with both tar files (55 MB and 77 MB). The files seem ok, I can open them with 7zip.
    My setup is basically the default with Pi2, Cirrus sound and LMS server. External hardware: Wifi stick, card reader with SD card for music files.
    Plugins:
    Audioplayer Einstellungen / Reboot WLAN & LAN Dateisystem Mount Squeezebox Server Jivelite Raspberry Einstellungen Passwortschutz Kodi / XBMC Bluetooth.

    Is there a way to prepare an image of the SD card within Windows? If not, I could also use a Linux live system if you tell me the command line. I could then upload the image file, so that you could debug it.

    🙂
    And while you’re at it:
    WPS does not work for me either. I have to use Access Mode instead.

    29. Mai 2018 at 12:01 #35948

    Hi Mike,

    If possible, try installing the exact same version of LMS as before to rule this out as a possible source of error.

    29. Mai 2018 at 18:24 #35962

    Hello Heiner,

    it doesn’t even work with the same LMS:
    I created a backup file with the „new“ LMS on Stretch image and tried to restore the same file on it. No success.
    Could it be a problem with access rights?

    31. Mai 2018 at 10:01 #35989

    Do you have password protection or write protection plugin enabled?

    2. Juni 2018 at 11:41 #36021

    No protections, but I experimented a little more:
    I have tried different sizes of tar files via WLAN and via LAN: One with 45 MB, the other with 55 MB.
    The smaller works, the larger not. This is true for two installations on different sd-cards (8 GB & 16 GB). WLAN or LAN makes no difference.

    I also made the larger file smaller by removing a large file (e.g. artwork.db): Now it works!
    So for now I will simply remove the folder „cache“ from the tar-file. I have to rebuild it anyway with a new installation of squeezeserver.

    4. Juni 2018 at 13:53 #36055

    Hi Mike,

    Thanks for the update. My tests probably all included ca 45 mb files as our test devices do not have big libraries. But we will check this out ourselves and see if it is a general issue.

Viewing 19 posts - 1 through 19 (of 19 total)

You must be logged in to reply to this topic.

Register here