Repository navigation
2.14.0
This one fixes a privacy hole in share links, and a bug in 2.13.1 that could destroy MP4 clips on some Debian 13 setups. If you share clips, read the first part: links you shared before this update stop working.
Share links no longer expose your other clips
A share link used to name the clip by its filename, like /c/Vice_Clip_12. Clip names are sequential, so anyone you sent one link to could change the number and watch the rest of your library. That held on the Cloudflare link and on your local network alike. Thanks to TinfoilyTim for reporting it (#222) and to def750 for raising it first (#213).
Share links now carry a random token instead, like /c/6wSLAdYsDF0_, and the public server accepts nothing else, so editing a link gets you nowhere.
- Every clip already in your library gets a token the first time Vice starts.
- A link keeps working when you rename its clip, and stops when you delete it.
- A new recording that reuses an old clip number gets a fresh link, so nobody holding the old one sees the new clip. That also stops Discord replaying a stale cached clip under a reused name.
Links you shared before this update no longer work. That is the fix rather than a side effect: a filename that still worked would leave the hole open. Copy a fresh link from Vice for anything you want to share again.
A share link also can no longer ask your machine to transcode a preview. That exists for Vice's own player, and over a link it let a stranger put your machine to work.
MP4 clips could be trimmed down to a single frame (#154)
On Debian 13, gpu-screen-recorder 5.13.3 can write MP4 files with every frame stamped at the same time, so FFmpeg can read only one frame of the whole recording. 2.13.1 took the frame count as the clip's length and let the file through, and the trim that cuts every clip to your chosen length then replaced the recording with that one frame. The version before at least left the file alone.
- Vice now checks how many frames FFmpeg can actually read before trusting the count. A file like this is left on disk untouched, with a message that says what is wrong with it.
- The trim now checks its own result before replacing anything. If the result comes out broken, Vice tries again with a re-encode, and keeps the whole clip if that fails too.
If you record MP4 on Debian 13 with Vice's installer, switch to MKV for now (Settings, Recording, Container). I'm asking upstream whether a newer gpu-screen-recorder fixes the files at the source. Thanks to LouReinaK for sharing the file that made this findable.
Also
- A clip that reads fine but reports no duration now says exactly that, instead of blaming ffprobe for giving no reason.
Install: yay -Syu vice-clipper, then open Vice.