Open Pegaze opened 12 years ago
The first two, I believe, are that the packaged app gets an ffmpeg binary distributed with it, which is not built normally.
I don't know offhand what's wrong with the second two. They sound related. I'll make sure to check them out.
That the up/down stats are cleared is a feature not a bug :-)
You can control this with the checkbox in
Settings->Privacy-> "Clear swarm up:down seed ratio on close"
If checked statistics about how much you have uploaded and downloaded in each swarm is never saved to the hard disk. I figured that we at least should allow users to not create a permanent record of their sharing stats on their hard drive. The per-swarms up:down stats are not used by the system for anything expect to make users feel good about seeding :-)
If I remember correctly the default is to save the stats, and you have to check the checkbox if you want them cleared. Search the code for "privacy.clear.seed.ratio.on.close" to find the implementation.
Heya Tomas
Yeah, seeding is good !
I have send my comment. Edit and re-edit it to finally delete it. It was wrong.
But this option does not seem revertible for me (or i will be totally shamed).
I'm running my 1S for time in the same working directory from the build 7603 to the latest git code. This feature, I set it just after it appears. Was a good idea to flush records ! I tried to undo but my 1S still do not remember anything after thousand of restarts.
I have to retry with a fresh homedir ...
That let me think that a good feature for 1S would be to be able to "export/import" the (already hashed / processed) Swarms.
Many user have (very) large number of shared files. Some of us (users) are hashing for days (one or two ;) on modern machines : Terra bytes of files are commons. To be able to reset our node quickly without loosing this and to have the capacity to backup all these works would be fine. :)
Better, to be able to choose to export / import Swarms, Friends and/or Keys.
Keep the Swarms online and take this new identity (and friends) for a moment ! I'm goinf to check my messages !! :)
Best regards, peg
First two were probably introduced in c54ce9450972569a782879d51c3bfcf86b3d363e
It looks like changing the header of OSF2FChannelDataMessages was a breaking change :)
b9c4b7217c2e423c9da89865d29a913d657d8a03 Undoes the breaking header. I'm not seeing errors, but still not seeing the transfer I'd expect. No errors in the log that are particularly suspicious either. @isdal, do you have pointers to classes to watch in particular to see what might be breaking.
Heya Devs,
Just a little note to report you some troubles with 1S from the Git code :
Cheers