Wow, its even more strange than I thought.
Ok, so a good reason why *not* to change the path, is that the PATH is the source of the BUG!!!! (yes really!)
With the path included in the file I always get the same behaviour, black images of the right size. Even if I send "640 480" to the correct inlet the behaviour is the same.
So I tried changing the path/filename, and BOOM everything works again.
/home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/mountains/cap
will not work (I did not try making a fake directory named like this for testing, but I suggest you give it a try to see if you get the same behaviour.)
BUT this path/filename DOES work:
/home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/cap
Interesting eh?
Also this is the source of the extension bug, If I use this message:
file /home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/mountains/cap 0
I get a bunch of black JPEGs! where 0 is named .tif.
If I use this (the same directory called from a relative path:
file test-captures/mountains/cap 0
I get a bunch of properly labelled TIFs not JPEGs.
I've pasted this email in the tracker for reference.
I guess the message/symbol is too long and causing problems?? I suggest trying to write to a file in a directory with 10 slashes, that should cover the bases!
Thanks Johannes,
B. Bogart
IOhannes m zmoelnig wrote:
hi
B. Bogart wrote:
Hey all,
I've tested this with a few different versions of Gem on my debian machines. All are etch with nvidia drivers from the repos.
I've attached the patch I'm using to test, remember to change the file path!
a good standard path is "/tmp" :-)
Anyone else running a debian etch machine and pix_write does work?
What's happening is files are created, at the right size, but always 100% black.
true, you discovered a bug. the workaround is to explicitely send the [pix_write] object the dimensions of the to-be-captured screen.
[loadbang]| [640 480( | | | [pix_write] |
Another oddness is that the first file created is named ".tif" even though "file" says it is a jpg. Subsequent files are .jpg as expected.
i cannot reproduce this. in your patch you set the type to "0" which is tiff - and tif it produces. when i set the type to "1" i get jpegs throughout.
mfga,sdr IOhannes