~/.winff/presets.xml file is not updated from updated /usr/share/winff/presets.xml file
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
winff (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
presets.xml still seems invalid:
[NULL @ 0x1e41aa0] [Eval @ 0x7fffe263a6d0] Invalid chars 'v' at the end of expression '4mv'
[NULL @ 0x1e41aa0] Unable to parse option value "4mv"
Invalid value '+4mv' for option 'flags'
Press Enter to Continue
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: winff 1.3.2-4ubuntu1 [modified: usr/share/
ProcVersionSign
Uname: Linux 3.0.0-12-generic x86_64
NonfreeKernelMo
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Sat Oct 15 00:56:08 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
PATH=(custom, user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: winff
UpgradeStatus: Upgraded to oneiric on 2011-10-01 (13 days ago)
Hmm, can't be "really":
paul@stromboli ~ $ grep 4mv /usr/share/ winff/presets. xml
paul@stromboli ~ $
But I expected this bug to appear. You updated winff from a previous version and winff unfortunately stores a copy of the above mentioned file in ~/.winff/ the first time it runs. So the package is fixed, but winff still uses the old file and the user has to replace (or merge in the case of local changes) the presets.xml file in the package with the presets.xml file in the user folder.
When no changes were made locally the procedure is simple (in a terminal window): presets. xml ~/.winff/ presets. xml.old
mv ~/.winff/
You can then start winff again. I propose to make the backup, just in case you discover that you did make relevant changes. Of course you can make rename that file also in you favorite file browser.
Unfortunately there is no plain method in packaging land to do such a thing in the package, so the only other option would be to fix winff to do that. Unfortunately, this has not been accomplished by upstream due to complexity to do it programmatic, and due to lack of urgency. It now hits us by an major change of ffmpeg, and has hit us long time in the past when we didn't understand the direction of the solution yet.