Not working on second run

[advilm]

The first time I run snap-sync everything seems to backup fine.

/backup/home:
56
/backup/media:
57
/backup/root:
106

However, when I run snap-sync again:

NOTE: Previous failed snap-sync backup snapshots found for 'root'.
Delete failed backup snapshot(s)? (These local snapshots from failed backups are not used.) [y/N]?

Creating new local snapshot for 'root' configuration...
Will backup //.snapshots/119/snapshot to /backup//root/119//snapshot
Proceed with backup of 'root' configuration [Y/n]?

NOTE: Previous failed snap-sync backup snapshots found for 'media'.
Delete failed backup snapshot(s)? (These local snapshots from failed backups are not used.) [y/N]?

Creating new local snapshot for 'media' configuration...
Will backup /media/.snapshots/66/snapshot to /backup//media/66//snapshot
Proceed with backup of 'media' configuration [Y/n]?

NOTE: Previous failed snap-sync backup snapshots found for 'home'.
Delete failed backup snapshot(s)? (These local snapshots from failed backups are not used.) [y/N]?

Creating new local snapshot for 'home' configuration...
Will backup /home/.snapshots/65/snapshot to /backup//home/65//snapshot
Proceed with backup of 'home' configuration [Y/n]?

Performing backups...

Sending incremental snapshot for 'root' configuration...
At subvol //.snapshots/119/snapshot
At snapshot snapshot
Deleting old snapshot for root...
Tagging local snapshot as latest backup for 'root' configuration...

Sending incremental snapshot for 'media' configuration...
At subvol /media/.snapshots/66/snapshot
ERROR: parent determination failed for 798
ERROR: empty stream is not considered valid
Exited due to error on line 484.
exit status: 1
command: $ssh btrfs receive "$backup_location"
bash line: 0
function name:

[ChrisLahaye]

Were you able to fix this issue?

[grgpw]

funny I had the same problem today :D
I found this thread on a mailing list:
https://www.spinics.net/lists/linux-btrfs/msg69369.html

changing "btrfs send -c" to "btrfs send -p" in the snap-sync script seems to work but that's no real solution.
my affected subvolume is in fact a top level subvolume, so creating a separate subvolume might solve this.
but I don't have the time to test this right now :/

[grgpw]

further reading and testing suggests "-p" is better suited (and more robust) or at least the same as "-c" anyway.

@qubidt
could this be changed or are there any problems to be expected I haven't thought about?
I'd gladly create a pull request.