Home of the Squeezebox™ & Transporter® network music players.
Page 6 of 11 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 102
  1. #51
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Thanks Paul

    I just discovered stderr, and indeed redirecting it to stdout as you indicated gets the output into the file. But that rolling progress cursor does make a very large number of lines in the output, so I'll give quiet mode a try.

  2. #52
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    ...and Quiet mode stops all output to stderr, so there's nothing at all to send to the log file! I guess I'll just leave it as was, and use my own echo statements to record what happened.

  3. #53
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by mrw View Post
    I use the tz=UTC mount option with my FAT drive, which causes Linux to interpret all timestamps as UTC, despite official FAT semantics.
    Any idea how to do this in pCP? I'm already experiencing 1-hour differences in time stamps between different FAT drives - some mounted locally, some mounted as network shares, and odd things seem to be happening. Sometimes a reboot seems to change the apparent timestamps in the files, so maybe it depends whether setting the clock completes before or after the disk is mounted.

    pCP has options for mounting disks, and I gather that those settings create the entries in /etc/fstab. If I attempt to edit the settings in that file they don't stick, presumably because pCP is running from ram. How should I go about trying to edit that file to add the 'tz=UTC' option? Does pCP recreate fstab each time it boots? Would I be better off not using the pCP mount options, and manually mounting the disks after the device has booted?
    Last edited by chill; 2019-05-10 at 01:00.

  4. #54
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    548
    Quote Originally Posted by chill View Post
    Any idea how to do this in pCP?
    No, because I'm not a user of pCP. I'll bet there is some kind of 'persistence' option.

    There is another rysnc option to consider: -c, --checksum skip based on checksum, not mod-time & size

    If your source is guaranteed to be 'truth', and the destination is simply a clone, then this might be a way to go. I don't know why I didn't mention it before. The process would consume more cpu cycles, but perhaps that won't be a practical issue.

    It's a while since I looked at rsync, and I haven't read and understood this entire thread, so I might be off target.

  5. #55
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Thanks - You're right that the target is simply a clone of the source. I did notice the checksum method, but I assumed that the extra CPU cycles would be significant, since it will have to calculate checksums for large audio files on both drives, whereas the size/time check is a relatively quick check of a couple of file attributes. It already takes my Pi Zero W about 12 minutes to determine that nothing needs to be updated! Maybe I should try it anyway.

    There is indeed a 'persistence' option in pCP, that allows certain files to be backed up. The home directory is included in the backup set by default, but I'll need to read up on how to do this for files that are in other places.

    Maybe I should just use a disk format more suited to Linux. I started out with the intention of being as compatible as possible across different operating systems, but I'm not sure that's really necessary - I'll always have something that can read a Linux disk.

  6. #56
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    2,919
    You could experiment with the "options" field in the "Setup Network Disk Mount" section in pCP web UI

    "<Options> are a comma delimited list of mount options. Ref mount man pages.
    CIFS
    vers=2.0 - The linux kernel now defaults to SMB version 3.0, versions must be specified.
    uid=1001 - mounts the drive with user "tc". Useful if using ssh sessions to write data to share.
    gid=50 - mounts the drive with group "staff". Useful if using ssh sessions to write data to share.
    NFS
    vers=3 - The linux kernel now defaults to NFS version 3, versions must be specified."
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  7. #57
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by Paul Webster View Post
    You could experiment with the "options" field in the "Setup Network Disk Mount" section in pCP web UI
    Thanks Paul - I spotted the options field for my network drive, but didn't play with the options. On the Pi Zero W that's handling the backup tasks, the main library disk is mounted as a network share from my main server (a Pi 3B+), and the backup disk is directly connected to the Pi Zero W.

    I suspect (just a guess really) that the CIFS share will get it's timetags and timezone information from the mount options on the host 3B+. And to be completely in control I'd also need to set the timezone for the locally mounted backup disk. Both of these lead to a requirement to set options for a locally mounted disk, and there isn't a field to do that in pCP.

    I'm starting to favour the use of a Linux disk format, in the hope that I'll be free of this issue altogether. Any suggestions as to which format would be optimal for speed, resilience, timezone compatibility etc?

  8. #58
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,065
    Quote Originally Posted by chill View Post
    I did notice the checksum method, but I assumed that the extra CPU cycles would be significant, since it will have to calculate checksums for large audio files on both drives, whereas the size/time check is a relatively quick check of a couple of file attributes. It already takes my Pi Zero W about 12 minutes to determine that nothing needs to be updated! Maybe I should try it anyway.

    Maybe I should just use a disk format more suited to Linux. I started out with the intention of being as compatible as possible across different operating systems, but I'm not sure that's really necessary - I'll always have something that can read a Linux disk.
    Checksumming will really slow syncing down - in order to calculate the checksums, each file has to be completely read.
    Try using the exfat file system - nearly as universally supported as fat32, 10ms timestamps. Or, if this isn't a requirement anymore, just use ext4.
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  9. #59
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by Roland0 View Post
    Checksumming will really slow syncing down - in order to calculate the checksums, each file has to be completely read.
    Try using the exfat file system - nearly as universally supported as fat32, 10ms timestamps. Or, if this isn't a requirement anymore, just use ext4.
    Thanks - does exfat also have the potential for ambiguity in the timezone?

  10. #60
    Senior Member Greg Erskine's Avatar
    Join Date
    Sep 2006
    Location
    Sydney, Australia
    Posts
    1,920
    Quote Originally Posted by chill View Post
    Any idea how to do this in pCP? I'm already experiencing 1-hour differences in time stamps between different FAT drives - some mounted locally, some mounted as network shares, and odd things seem to be happening. Sometimes a reboot seems to change the apparent timestamps in the files, so maybe it depends whether setting the clock completes before or after the disk is mounted.

    pCP has options for mounting disks, and I gather that those settings create the entries in /etc/fstab. If I attempt to edit the settings in that file they don't stick, presumably because pCP is running from ram. How should I go about trying to edit that file to add the 'tz=UTC' option? Does pCP recreate fstab each time it boots? Would I be better off not using the pCP mount options, and manually mounting the disks after the device has booted?
    Hi chill,

    RE: pCP

    /etc/fstab is generated on every boot of piCore. See [Main Page] in [Advanced] mode > [Diagnostics] > [Boot Process] and look for "rebuildfstab" (ctrl F).

    The "rebuildfstab" script can be run anytime to generate a new /etc/fstab. rebuildfstab also adds the "noauto" option so "mount -a" doesn't work.

    I use Paul's [LMS] page for mounting extra partitions. Works for great for me.

    There is a "nofstab" boot code. See [Main Page] in [Beta] mode > [Extras] > [Bootcodes]. I haven't used it but it should prevent /etc/fstab from being auto generated. You could make your own fstab and add it to /opt/.fileoot so it gets added to mydata.

    regards
    Greg

Posting Permissions

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