Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22
  1. #11
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,603
    Quote Originally Posted by kidstypike View Post
    I'd go for 2000MB minimum.

    Mine below.

    Attachment 33007
    Yup mine is 1.1 GB

    Sent from my Pixel 3a using Tapatalk

  2. #12
    Junior Member
    Join Date
    Dec 2019
    Posts
    21
    Quote Originally Posted by slartibartfast View Post
    Yup mine is 1.1 GB

    Sent from my Pixel 3a using Tapatalk
    Is there a downside to maximizing it?

  3. #13
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,976
    Quote Originally Posted by DavJon View Post
    Is there a downside to maximizing it?
    In general no - but it depends how you make backups and eventually restore.

    If you make a backup by doing a simple SD card to SD card copy then you might find that the original 32GB SD (or whatever) will not fit on another SD card that claims to be the same size.

    If you do not make backups ... or you do it a different way then maximizing is fine.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  4. #14
    Senior Member
    Join Date
    Jul 2020
    Posts
    261
    Quote Originally Posted by Paul Webster View Post
    In general no - but it depends how you make backups and eventually restore.

    If you make a backup by doing a simple SD card to SD card copy then you might find that the original 32GB SD (or whatever) will not fit on another SD card that claims to be the same size.

    If you do not make backups ... or you do it a different way then maximizing is fine.
    I had noticed that backup issue before, but didn't realise it was related to this. I use 64GB cards now (the price difference is not that much), based on my unconfirmed belief that larger disks are less likely to wear out. (that is assuming broken blocks get allocated somewhere else, which I do not know is true )

    But currently I can only choose up to 2000Mb or the whole disk. When I started testing the integration of streaming services into the Library the scan process froze halfway in caching artwork.. So maybe it would be useful to have more options there that get closer to the full size, without using the whole card....?

  5. #15
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,976
    Yep - more sizes or a percentage would be nice.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  6. #16
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,095
    I've now switched to keeping the cache on a third partition on the boot/root drive. This has mostly advantages, but also one disadvantage.

    Advantages:
    - The Root partition doesn't have to be very big. Mine is 1000MB, but I've just checked and I'm only using just over 150MB. I keep a daily backup image of the drive, using 'dd' piped through 'gzip', up to the end of the second ('root') partition (see below). The size of that backup image is then quite manageable and can be restored onto almost any card or USB flash drive.
    - The third partition can be made to fill the remainder of the card/drive, so the cache size is as good as unlimited. I also back up this cache on a daily basis, but I use a simple file based copy (rsync) of the slimserver folder.
    - If the cache becomes corrupted somehow (and I can't remember the last time it did so) it shouldn't take down the whole card. I can copy the most recent backup of the slimserver folder back onto the third partition and that should get me up and running again. If that doesn't work I would have to resort to the dd image of the first two partitions and then copy the slimserver folder over as well.
    - since the third partition has so much spare space, I use it to also store the dd image of the first two partitions temporarily before copying that file to another machine overnight.

    Disadvantage:
    -The presence of the third partition means pCP's resize function is no longer available, so if I ever need to expand the Root partition I'll have to resort to doing it manually with other tools. To make this a simpler process I have deliberately left quite a big gap between the end of the second partition and the start of the third partition. This means I can expand the second partition without affecting the cache. But this isn't really necessary - without that gap I could simply delete the third partition, expand the second, recreate the third and then copy the slimserver backup over again.

    I've also started using a USB3 flash drive to boot from, rather than an SD card, mostly because it's physically easier to access with my RPi inside the Argon One case. This means the boot device is no longer mmcblk0. I haven't fully got my head around the device assignment yet, but it seems that the Boot/Root device isn't always on sda, and possibly depends which USB socket I use or what other drives are present. So my backup script has to try to figure out where the Pi booted from. I'm not sure quite how that should be done, but my approach at the moment is to check where the tce/optional packages are. If there's a better way I'm all ears.

    Code:
    #!/bin/sh
    
    imagefile=$1
    
    #Find which device pCP booted from: it's the one that has all the tce/optional packages
    bootdev=$(mount | grep -m 1 tce/optional | awk -F\/ {'print $3'})
    device="${bootdev::-1}"
    echo $device
    
    bs=$(fdisk -l | grep -A 3 $device":" | grep Units: | awk -F= {'print $2'} | awk {'print $1'})
    echo "blocksize="$bs
    
    count=$(fdisk -l | grep $device"2" | awk {'print $5+1'})
    echo "count="$count
    
    dd if=/dev/$device bs=$bs count=$count | gzip > $imagefile

  7. #17
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,976
    Quote Originally Posted by chill View Post
    So my backup script has to try to figure out where the Pi booted from. I'm not sure quite how that should be done, but my approach at the moment is to check where the tce/optional packages are. If there's a better way I'm all ears.
    This might help ...
    Code:
    set | grep mmc
    BOOTDEV='/dev/mmcblk0p1'
    BOOTMNT='/mnt/mmcblk0p1'
    TCEDEV='/dev/mmcblk0p2'
    TCEMNT='/mnt/mmcblk0p2'
    Last edited by Paul Webster; 2021-01-19 at 07:35.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  8. #18
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,095
    Quote Originally Posted by Paul Webster View Post
    This might help ...
    Code:
    set | grep mmc
    BOOTDEV='/dev/mmcblk0p1'
    BOOTMNT='/mnt/mmcblk0p1'
    TCEDEV='/dev/mmcblk0p2'
    TCEMNT='/mnt/mmcblk0p2'
    Perfect, thank you!

    Code:
    tc@pCPServer:~$ set | grep BOOTDEV
    BOOTDEV='/dev/sdb1'

  9. #19
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,095
    Tsk - nothing is EVER as easy at it seems in Linux!

    'set' doesn't include BOOTDEV, BOOTMNT, TCEDEV or TCEMNT when run from a script. So I've resorted to creating TCEDEV the same way that it's done for a terminal shell, as given in /home/tc/.ashrc


    Code:
    #!/bin/sh
    
    imagefile=$1
    
    #Find which device pCP booted from: command copied from /home/tc/.ashrc
    TCEDEV="/dev/$(readlink /etc/sysconfig/tcedir | cut -d '/' -f3)"
    device="${TCEDEV%%?}"
    echo $device
    
    #bs=$(fdisk -l | grep -A 3 mmcblk0: | grep Units: | awk -F= {'print $2'} | awk {'print $1'})
    bs=$(fdisk -l | grep -A 3 $device: | grep Units: | awk -F= {'print $2'} | awk {'print $1'})
    echo "blocksize="$bs
    
    count=$(fdisk -l | grep $TCEDEV | awk {'print $5+1'})
    echo "count="$count
    
    dd if=$device bs=$bs count=$count | gzip > $imagefile

  10. #20
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,976
    The "set" was just to show you how to see the environment variables and filter them to pick one.
    You could then use it like this ...
    Code:
    tc@PiTouch:~$ ./test.sh $BOOTDEV
    Booted from /dev/mmcblk0p1
    Code:
    tc@PiTouch:~$ cat test.sh
    #!/bin/sh
    echo "Booted from $1"
    However, that might not work from a cron job ... so copying the pCP way of doing it is wise.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

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
  •