Hi list,
I have a serious issue with a patch that loads and displays images and films sequentially in a loop of about 5 min. Everything works fine, but after two hours, we got blank screen and Pd says : [pix_image] : Unable to find file ... The path displayed is always the correct one, so the files exist, but Gem can't find it.
Any idea of what is going on ?
This occurs for almost every instance of pix_image and pix_film. (one .avi seems to survive each time) I'm on windows 7 64bits with pd-extended 0.42.5 anf Gem 0.92.3
Any advice would be very very appreciated.
Thanks !
David
I've been able to reproduce the bug. See attached patch. The metro opens the same 2 files, it works for 30 seconds,the RAM doesn't grow, and then Pd says
error: GemImageLoad: Unable to find file. And then, if I want to save my example patch, Pd says : error : too many open files.
Is this a bug of pix_image ? Is there a limit of opened files somewhere ? How can I avoid that ?
Thanks.
David
De : david lemarechal d_lemarechal@yahoo.fr À : "pd-list@iem.at" pd-list@iem.at Envoyé le : Mardi 21 Juin 2011 16h50 Objet : [PD] pix_image and pix_film : Unable to find files after two hours
Hi list,
I have a serious issue with a patch that loads and displays images and films sequentially in a loop of about 5 min. Everything works fine, but after two hours, we got blank screen and Pd says : [pix_image] : Unable to find file ... The path displayed is always the correct one, so the files exist, but Gem can't find it.
Any idea of what is going on ?
This occurs for almost every instance of pix_image and pix_film. (one .avi seems to survive each time) I'm on windows 7 64bits with pd-extended 0.42.5 anf Gem 0.92.3
Any advice would be very very appreciated.
Thanks !
David _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-21 17:36, david lemarechal wrote:
Is this a bug of pix_image ? Is there a limit of opened files somewhere ? How can I avoid that ?
it's a bug in Pd, that has been fixed with 0.43 unfortunately, Gem will also have to adapt to the fix in Pd (read: you need a version of Gem specially compiled for Pd-0.43)
fgmadr IOhannes
Oh my god that's bad news... How many files is the "limit"?
Do text files opened with [textfiles] also count?
On 06/21/2011 06:43 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-21 17:36, david lemarechal wrote:
Is this a bug of pix_image ? Is there a limit of opened files somewhere ? How can I avoid that ?
it's a bug in Pd, that has been fixed with 0.43 unfortunately, Gem will also have to adapt to the fix in Pd (read: you need a version of Gem specially compiled for Pd-0.43)
fgmadr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4AyjcACgkQkX2Xpv6ydvRS3ACgivcnibKHwQ/19gJNsuH3g70+ 7X8An2EyuVLyLvEMf/ZI9UXGyf1zq6mv =FC8L -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/21/2011 07:11 PM, Matteo Sisti Sette wrote:
Oh my god that's bad news... How many files is the "limit"?
dunno, probably depends on your system
Do text files opened with [textfiles] also count?
no. the problem is, that pd and an external like Gem might use a different libc library. if the file is opened from within pd.dll, it might be impossible to close from Gem.dll, leaving a dangling file reference.
since [textfile] lives withing pd.dll, it will use the same libc implementation to open and close the file-handle, and thus everything works as expected. however, when using any external, the problem might occur.
note, that most externals bundled with PdX probably won't exhibit the problem, as they are all compiled and linked against the same libc. Gem is different, as PdX simply includes a pre-compiled binary (compiled with M$VC)
with Pd-0.43, there is finally a sys_close() function, that closes a filehandle opened within pd.dll within the same context.
fmasdr IOhannes