quoted

BTW, I restored and mounted your 20160307-fanbtr-image:

[266169.207952] BTRFS: device label fanbtr devid 1 transid 22215732 /dev/loop0
[266203.734804] BTRFS info (device loop0): disk space caching is enabled
[266203.734806] BTRFS: has skinny extents
[266204.022175] BTRFS: checking UUID tree
[266239.407249] attempt to access beyond end of device
[266239.407252] loop0: rw=1073, want=715202688, limit=705760000
[266239.407254] BTRFS error (device loop0): bdev /dev/loop0 errs: wr
1, rd 0, flush 0, corrupt 0, gen 0
[266239.407272] attempt to access beyond end of device
.. and 16 more

As a quick fix/workaround, I truncated the image to 1T

The original fs was 417 GiB in size. What size does the image claim?

ls -alFh  of the restored image showed 337G I remember.
btrfs fi us showed also a number over 400G, I don't have the
files/loopdev anymore.
It could some side effect of btrfs-image, I only have used it for
multi-device, where dev id's are ignore, but total image size did not
lead to problems.

[10/509]mh@fan:~$ sudo btrfs check /media/tempdisk/
Superblock bytenr is larger than device size
Couldn't open file system
[11/509]mh@fan:~$

Can this be fixed?

What I would do in order to fix it, is resize the fs to let's say
190GiB. That should write correct values to the superblocks I /hope/.
And then resize back to max.
Maybe btrfs check --repair can also fix it, but before doing --repair
or other actions, I would see what else besides btrfs could be wrong,
see also suggestion of Holger. --repair can repair certain things, but
also destroy the fs.