Closed GoogleCodeExporter closed 9 years ago
there's another problem besides windows 7. I have run it for a few months now
on
windows 7.
Original comment by bgg...@gmail.com
on 4 Oct 2009 at 3:32
Happens to me the exam same way as jak.spalding. I'm running the 64bit RC1
that's
fully updated as of today (10/16/2009)
Original comment by jor...@gmail.com
on 16 Oct 2009 at 4:36
My Windows 7 is 64-bit RTM. Could it be that being 64-bit is the issue?
Original comment by jak.spalding
on 16 Oct 2009 at 4:45
i am typing the message in windows 7, and have not had a problem yet
Original comment by bgg...@gmail.com
on 17 Oct 2009 at 5:35
@bggmtt: are you running 32 or 64 bit?
Original comment by jak.spalding
on 17 Oct 2009 at 6:18
64 bit. It's probably international characters in the paths
see issue 10 http://code.google.com/p/winff/issues/detail?id=10
Original comment by bgg...@gmail.com
on 20 Oct 2009 at 8:25
Same problem here. Crashes when selecting device preset.
Windows 7 ultimate, final RTM. 64 bit.
Thanks
Mike
Original comment by mcd...@gmail.com
on 25 Oct 2009 at 11:11
I am having the exact same problem. Interesting though, I can select PAL DVD HQ
Widescreen device preset, and WinFF doesn't crash... Pretty much any other
preset and
WinFF crashes (I haven't tried them all, but I have tried 85%+ of the default
presets).
This is happening in Windows 7 professional.
Clean install, then instaled k-lite codec pack, ffdshow, autogordian knot,
virtual
dub, and winff.
Any insight? I have uninstalled and reinstalled everything with no luck.
I am going to create a few presets and see if I can isolate the issue tonight.
The crash has nothing to do with the international characters issue.
1. I am in North America and don't have any on my PC.
2. WinFF crashes only when the device preset is changed. The path for the file
doesn't even need to be input. Only selecting the device preset will cause the
crash/closing of WinFF.
Original comment by chris.s....@gmail.com
on 2 Nov 2009 at 3:01
Setting this bug to "new" again. Looks like this is a real bug to me.
@Matt: you can kick me off now, if you think I am misjudging your judgement. ;)
Original comment by poipodec...@hotmail.com
on 2 Nov 2009 at 3:49
A bit of an update on this issue...
I played around with WinFF last night for about 30 min and found something
interesting.
WinFF never remembers any settings (for me) in Windows 7 64bit.
Every time I load WinFF the "convert To..." field is empty (not that it is an
issue,
but I think this field might be part of the problem).
Also of note; when the "Convert to..." field is blank, then the device preset
list is
not in alphabetical order (again, not an issue).
When this is the case (assuming I skip the "Convert To..." selection and leave
it
null) and I specifically set the "Device Preset", 90% of the time (or more)
WinFF
crashes. It does not matter if a movie/video file has been added yet.
IF I select "------" in the "Convert To field" the "Device Preset" options are
listed
in alphabetical order. At this time, if I select a "Device Preset," WinFF only
crashes about 60% of the time.
If I filter the "Device Preset" field by specifying a "Convert To..." type,
WinFF
crashes 100% of the time in my limited testing.
Finally, if I create a new preset and the "Convert To..." field is left blank,
the
custom (or new) device presets will show up at the very bottom of the "Device
Preset"
listings. When I select them under these conditions, WinFF only crashes about
15% of
the time.
Original comment by chris.s....@gmail.com
on 3 Nov 2009 at 3:26
Suspect its minor difference between WinXP and Win7 in terms of access to home
folder
/ config settings folder.
Will try and test on Win7 and report back.
Original comment by istoff@gmail.com
on 4 Nov 2009 at 2:08
Did initial testing using 1.1
Did not encounter problems.
Have not got multiple video tools installed. Just winff, though.
Original comment by istoff@gmail.com
on 5 Nov 2009 at 12:04
i just don't see it. I am running win7 64bit. As far as the folders, win7 is a
cleaner path than xp.
win7 is c:\users\username
winxp is c:\documents and settings\username
although there is a new lazarus .928.2 out and it has a lot of bug fixes for
the
components that mentioned win 7. So that will most likely fix it.
Original comment by bgg...@gmail.com
on 5 Nov 2009 at 5:53
i have completely wiped the hard drive, reinstalled win7, and have the exact
same
results.
WinFF still crashing on a regular basis.
Original comment by chris.s....@gmail.com
on 7 Nov 2009 at 11:47
Chris.
Would you consent to me attempting a remote viewing session using a product like
teamviewer or something similar?
Possibly we could skype and look at the problem as well?
istoff gmail com
I'm in timezone +0200 so available for another 5 or 6 hours today.
Original comment by istoff@gmail.com
on 8 Nov 2009 at 3:06
sorry to just now be getting back to you.
I think it might be a bit difficult for us to get together on a remote session
(not
that I am against it... just time differences / work schedules... make it a bit
difficult.
I will try to get a screen capture / video for you guys that might give you a
better
picture of what is going on with the program.
I am willing to try any ideas, or make any changes you recommend.
Original comment by chris.s....@gmail.com
on 9 Nov 2009 at 3:18
I'm intrigued by your previous post about presets appearing not to be loaded and
saved correctly.
perhaps if you describe that situation from a fresh install of winff. Backup
any
presets you may have done your self and remove the .winff settings folder and
try
again, making a note of any unusual messages / behaviour.
Original comment by istoff@gmail.com
on 9 Nov 2009 at 9:36
here is link to a quick video:
http://vimeo.com/7511740
Presets are saved in winFF (when I create a new one), but when I load the
program, it
doesn't remember what was last selected if it crashed on the previous load,
assuming
conversion never started.
IF I can get it to run (convert a file), WinFF remembers the last setting
selected.
Even when winFF runs, it still crashes during the conversion.
The file will be converted if I can get a conversion started, but you will see
it
still crashes once the cmd line is started.
Hopefully the video will help provide some insight.
Original comment by chris.s....@gmail.com
on 9 Nov 2009 at 1:37
quick questions.
if you display the ffmpeg commandline as per the options menu. copy and run
that
command line conversion from the windows command prompt, does it still crash??
Also, to clarify, does the conversion crash while ffmpeg is running or does the
crash
occur inside winff?
Original comment by istoff@gmail.com
on 9 Nov 2009 at 3:38
"if you display the ffmpeg commandline as per the options menu. copy and run
that
command line conversion from the windows command prompt, does it still crash??"
I don't know... I never thought of trying that... But I DOUBT it will crash. I
will
try tonight. The problem seems to be in the WinFF GUI.
"Also, to clarify, does the conversion crash while ffmpeg is running or does the
crash occur inside winff?"
Crash is in WinFF. Always.
Once the command line is running, winFF crashes, but the cmd line runs, and
file will
be created.
I have learned to deal with this, as it works about 15% of the time. The trick
is to
run a setting once, and just stick with it.
As long as I leave the last ran preset as the preset I want to run, and don't
switch
presets, WinFF will start a cmd line, and begin running. (WinFF will still
crash once
the cmd line begins. Always.)
The problem is switching what preset I want to run.
When switching presets in the WinFF GUI, WinFF crashes 65%+ of the time.
I also have not experimented with setting up multiple videos to convert in
WinFF,
then selecting convert.
I don't know if 1, 2, 3, or all will execute since WinFF crashes once the cmd
is began.
Original comment by chris.s....@gmail.com
on 9 Nov 2009 at 4:04
watched video. took forever to load, but it answered my second question.
last questions.
does this occur with a default presets file?
does your user have full rights to the output folder?
Original comment by istoff@gmail.com
on 9 Nov 2009 at 4:05
Sorry the video took so long to load. Vimeo is generally pretty good, but their
server's seem slow today.
Default presets are the biggest problem.
When I create my own, the generally load. Not always, but a much higher chance
of
loading.
Whether default preset, or user created preset, WinFF always crashes once
conversion
begins.
The user account has full rights to output folder. Currently I have the output
folder set to the desktop. At the end of the video, you will see the file
created
appearing at the top left of the screen. That is the newly created file.
Original comment by chris.s....@gmail.com
on 9 Nov 2009 at 5:38
This appears to be a seperate issue from the one I reported although I have no
way of knowing for sure.
In my experience I can not even start the conversion due to program crashing
before I can click to start.
Original comment by jak.spalding
on 9 Nov 2009 at 6:41
does it crash when you select a preset?
Mine would crash almost every time, but messing with the presets, it loads once
in
awhile.
If yours crashes like mine (as in the video) you will see mine crashes on preset
selection too. I have just found that by creating a custom preset, it doesn't
crash
as often.
Original comment by chris.s....@gmail.com
on 9 Nov 2009 at 7:22
could you check in the eventlog (control panel, administrative tools) for any
error
messages that could give more info?
it may not be logged there, though, but possibly we could get more info.
Original comment by istoff@gmail.com
on 10 Nov 2009 at 4:28
Faulting application name: winff.exe, version: 1.1.0.0, time stamp: 0x4a976959
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x7406e294
Faulting process id: 0x6fc
Faulting application start time: 0x01ca60cbbd06ff4a
Faulting application path: C:\Program Files (x86)\WinFF\winff.exe
Faulting module path: unknown
Report Id: 0522521e-ccbf-11de-aa6c-001167600d8c
- System
- Provider
[ Name] Application Error
- EventID 1000
[ Qualifiers] 0
Level 2
Task 100
Keywords 0x80000000000000
- TimeCreated
[ SystemTime] 2009-11-08T23:42:29.000000000Z
EventRecordID 1948
Channel Application
Computer i7
Security
- EventData
winff.exe
1.1.0.0
4a976959
unknown
0.0.0.0
00000000
c00000fd
7406e294
760
01ca60cd1b87f828
C:\Program Files (x86)\WinFF\winff.exe
unknown
600553b2-ccc0-11de-aa6c-001167600d8c
Original comment by chris.s....@gmail.com
on 10 Nov 2009 at 11:56
> Faulting application path: C:\Program Files (x86)\WinFF\winff.exe
Would it be possible that somewhere inside winff doesn't like the brackets?
(x86)...
Original comment by poipodec...@hotmail.com
on 10 Nov 2009 at 1:10
will try and see if it affects mine. will reinstall to a similarly named
directory
and test on win7.
Original comment by istoff@gmail.com
on 10 Nov 2009 at 9:01
Nope.
Still working perfectly. ;(
I have no idea what could be causing this problem.
Original comment by istoff@gmail.com
on 11 Nov 2009 at 4:31
for the record, me running 32 bit win7 on test machine
Original comment by istoff@gmail.com
on 11 Nov 2009 at 4:31
fyi...
I am more than happy to try suggestions, but at this point, I have pretty much
given up.
I reinstalled windows again, for the 3rd time.
Format, install windows, install WinFF.
WinFF is the only thing I installed after windows updates.
After this install, Winff only crashes about 30% of the time when selecting a
preset.
WinFF does not 'stop responding' after conversion begins which is different than
previous installs.
Since I mainly only using WinFF to convert files from .ts to .avi (for editing
in
virtual dub), this will work for me because I generally do not switch between
presets.
As long as I don't change the presets, WinFF works fine.
This time around, I only experience a crash if I change presets.
No crashing after conversion has started.
For reference, my system:
Windows 7 professional, 64 bit
ASUS P7P55D PRO LGA 1156 Intel P55 ATX Intel Motherboard
i7-860 Intel processor
2x2GB OCZ ram
60GB OCZ SSD (OS hard drive)
Original comment by chris.s....@gmail.com
on 11 Nov 2009 at 8:57
Am in the process of "obtaining" win7 64 bit. hope to run it in a virtual
machine as
I don't have a suitable machine to install it on.
thanks for your patience.
Original comment by istoff@gmail.com
on 12 Nov 2009 at 10:22
*SIGH*
I have installed Windows7 64 bit.
I have *NOT* patched it or loaded antivirus.
I installed winff 1.1 into the default folder (Program Files (x86)
NOT crashing at all.
Am incredibly frustrated.
What I intend doing is putting some extra logging messages into my test version
and
send you a copy when it's usable. Possibly it can trace the execution line by
line
until it crashes and then we'll have an idea of when it crashes, although
probably
not why!
Original comment by istoff@gmail.com
on 12 Nov 2009 at 12:14
What's your development environment?
I'm a software engineer by day, although limited to .NET.
I could try and debug it?
Original comment by jak.spalding
on 12 Nov 2009 at 12:34
istoff (and everyone else), I really appreciate all your assistance on this. I
am in
the same boat as you, banging my head on the wall in frustration.
WinFF is a great tool, and I have been using regularly since I found it. I will
continue to use it, and appreciate all the work of those who developed this
tool.
I am starting to think it is something I am doing, or a system incompatibility
issue
on my end, as I seem to be the only one experiencing this problem to this
degree.
At least the program is no longer crashing for me when I begin conversion...
Only
when I am trying to switch presets. And only about 30% of the time.
Again, I find this to be an acceptable amount (considering how often it crashed
the
last time around).
Unless people come out of the wood work reporting the same issue, I would table
this
for the time being, and just consider it a 'user error' or 'system
incompatibility'
problem on my part.
If others start to show up reporting the same problem, then re-open the issue.
Also, if there is anything else I can do, just let me know.
Thank you,
Chris
Original comment by chris.s....@gmail.com
on 12 Nov 2009 at 2:11
I think i found it and will put out a test version here soon
Original comment by bgg...@gmail.com
on 12 Nov 2009 at 5:14
@jak
I develop and test in Linux using Lazarus.
I occasionally compile and test on a WinXP Virtualbox session. I now have a
Win7 64
bit session as well due to this annoying bug.
My tracing has lead to a minor difference between win32 and win64 which we will
attempt to resolve.
@chris
again, thanks for your patience on this one
we don't have a huge army of developers on our side, but we believe in making
winff
work as reliably as is humanly possible, given our constraints.
thanks again for your testing and video. it *DID* help a lot.
Original comment by istoff@gmail.com
on 12 Nov 2009 at 8:17
After having the same problem as the OP, I rolled back to the previous version
of
WinFF (1.0.4) and it seems to be working ok now. WinFF no longer closes
mysteriously.
Original comment by thegooddale
on 20 Nov 2009 at 9:26
I am having a crash on Win 7 x64, too, not sure if it is related, but the
"workaround" seems to work beautifully. I have only tried using the preset for
Blackberry-Blackberry Curve Fullscreen, and every time I click the Convert
button, I
get a message popup saying WinFF has crashed. I'll paste the event details
further
on. But behind that window, the script has already begun transcoding, and if I
don't
close the message box alerting me of WinFF's crash, the script will run just
fine,
all the way to the end, and the video plays beautifully on my Blackberry. So
while it
is a pain, and a crash is never fun, at least it does get the job done. I am
guessing
that if I were to use the command to copy the script command, I could probably
exit
WinFF gracefully. I can try to do so and report back here if you are interested.
Now for the details of the crash from event viewer:
First an Event ID 1000, source Application Error, details:
Faulting application name: winff.exe, version: 1.1.0.0, time stamp: 0x4a976959
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x7548e294
Faulting process id: 0x968
Faulting application start time: 0x01ca715c69f21812
Faulting application path: C:\Program Files (x86)\WinFF\winff.exe
Faulting module path: unknown
Report Id: eb4c366b-dd4f-11de-b8b6-005056c00008
Next comes Event 1001, WER, details:
Fault bucket 1584562412, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: winff.exe
P2: 1.1.0.0
P3: 4a976959
P4: StackHash_ee53
P5: 0.0.0.0
P6: 00000000
P7: c00000fd
P8: 7548e294
P9:
P10:
Attached files:
C:\Users\Will\AppData\Local\Temp\WER7A6D.tmp.WERInternalMetadata.xml
These files may be available here:
C:\Users\Will\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_winff.e
xe_662a886c4c1b76b89f49ce41fc1a8c845d5ef_022b99a0
Analysis symbol:
Rechecking for solution: 0
Report Id: eb4c366b-dd4f-11de-b8b6-005056c00008
Report Status: 0
I will attach the files in case they will help you.
Original comment by cyclomet...@gmail.com
on 30 Nov 2009 at 1:50
Attachments:
I have a test executable. There are a lot of other changes and some new
features may
not because they are not finished yet. Just looking to see if i got the problem
fixed
for win 7. I still have not had a problem on win 7 x64 myself. Just replace
winff.exe
in c:\program files (x86)\ with this one:
http://winff.googlecode.com/files/winff-testwin7.zip
Original comment by bgg...@gmail.com
on 18 Dec 2009 at 4:35
I'm no longer having any issue with the new test executable.
There's only an unrelated item with Windows 7's new "Libraries" feature but
that's
really not all that important!
Original comment by jak.spalding
on 19 Dec 2009 at 10:36
Same problem as the OP. After reading the discussion here, I tried the work
around
with no improvement. I'm running a fresh install of Win7 x64, only have updates
and
Office 2010 beta x86.
I did have some success when I made my own preset. Winff crashes but only after
I
click convert. Then the command prompt opens and conversion starts.
I noticed the fact that none of my settings are saved also.
It should be working, I've had 1.1 installed on my x86 machine without a
problem. I
suspect this is an issue that I am incapable of solving on my own, your help is
much
appreciated.
Error in the event log:
Faulting application name: winff.exe, version: 1.1.0.0, time stamp: 0x4b2b048b
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x7591e254
Faulting process id: 0x1690
Faulting application start time: 0x01ca83a02207acd2
Faulting application path: C:\Program Files (x86)\WinFF\winff.exe
Faulting module path: unknown
Report Id: c9428292-ef94-11de-9f09-002219e8cd6d
Original comment by Newell.D...@gmail.com
on 23 Dec 2009 at 8:19
i think you miss read it. It's not when clicking convert. It's crashes when
selecting a
preset.
Original comment by bgg...@gmail.com
on 23 Dec 2009 at 9:54
It might be the same as issue 51
Original comment by bgg...@gmail.com
on 23 Dec 2009 at 9:56
i think you miss read it. It's not when clicking convert. It's crashes when
selecting a
preset.
Sorry for not clarifying, no i didn't miss read it. I should've said it crashed
after selecting a preset, like the OP, UNTIL I did what you said and that was
install the workaround .exe. After that it did last long enough to click
convert. So
your workaround fixed the preset selection for me, and for that I thank you
very
much.
Original comment by Newell.D...@gmail.com
on 24 Dec 2009 at 3:36
So essentially that's 2 positive results for the new exe for this particular
issue.
Thanks bggmtt.
Original comment by jak.spalding
on 24 Dec 2009 at 8:14
Hi, I have confirmed that the test executable is working with my version of
Windows 7.
If you decide to deploy another version and need testing assistance, I am a QA
systems
tester for a university and would be happy to assist.
Original comment by DUDEN...@gmail.com
on 5 Jan 2010 at 2:40
winff-testwin7.zip crashes on me if I choose Audio/MP3 preset every time. It
does
crach less than the stable version for me. I'm running Win7 64-bit.
Original comment by sys32...@gmail.com
on 5 Jan 2010 at 11:22
PS: When the winff-testwin.zip verion of winff crashes on me when choosing the
Audio/MP3 preset, it does not write an error in event log under Application. The
stable version does write an event log. Both crash the same way as in the video
posted above.
Original comment by sys32...@gmail.com
on 5 Jan 2010 at 11:32
I also have a problem with 1.1 on windows 7 64bit
I'm now using the test exe and its at least working for most of the presets
Quicktime -> Quicktime MOV or Quicktime H.264 Video (very high quality) crash
for me
Ok this is funny.. I can select the top 2 presets on any category if I go any
lower
then the top 2 is crashes
Original comment by AriB...@gmail.com
on 11 Jan 2010 at 9:12
Original issue reported on code.google.com by
jak.spalding
on 3 Oct 2009 at 9:06