| Summary: | Playing tempfiles in kaffeine | ||
|---|---|---|---|
| Product: | [Applications] kaffeine | Reporter: | Petr Kopecký <kejpi> |
| Component: | general | Assignee: | Christophe Thommeret <hftom> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | faure, orzechowskip |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Petr Kopecký
2004-12-03 17:44:27 UTC
I could reproduce this problem with KDE 3.3.1 as well as with a recent CVS HEAD. Additional info: My System: Debian (so this is not Gentoo-specific) - KDE 3.3.1 from Debian Sid - KDE CVS HEAD compiled from source It seems to work for me with some attachments (images opening in kuickshow), but not with others (mpgs opening with kaffeine). The images don't seem to be saved to a subfolder (so the path passed to the application is correct), but movies are. This bug seems to be fixed in KDE 3.4.0. It works now (KDE 3.4 experimental packages on Debian Sarge) with an email that reproduced the error in 3.3.1 and CVS of that time. @Petr: Could you (as the reporter) please retry it with KDE 3.4 so this bug report can be closed? Hmm. There still is an error. Kaffeine *does* now play the movie I had as attachment in the test mail, but only the first time. As soon as I hit the play button to restart the mpg kaffeine complains that it cannot find the file /tmp/kde-cmueller/Redlight.mpg_[l56Dsc].mpg. The process list shows the (wrong) command line: kaffeine /tmp/kde-cmueller/Redlight.mpg_[l56Dsc].mpg The respective attachment is saved under: /tmp/kde-cmueller/kontactRDwrlc.3/Redlight.mpg The first time it plays the movie so the correct location must have been passed, but also the wrong one... this looks even stranger to me than the original bug... *** Bug 141077 has been marked as a duplicate of this bug. *** I suspect this is just bug 130709 But there are two temp file locations involved. Does that mean that Kmail saves the attachment twice in this case? Once for itself and once for the app that is started when one clicks on the attachent icon? If that were true then it would indeed look like a dupe of #130709. Still reproducible in KDE 3.5.6, BTW. Yes, there are two temporary files involved (but not saved twice, one is just hard linked to the other). This was introduced to fix bug 39537. See bug 130709 for a patch to fix. @Jonathan: Thanks for the explanation. I've seen the patch and your comment in the other bug. If I understand correctly it delays deletion of the file so that the application forked by the wrapper can start up and open the file before it's deleted. As long as it keeps the file open the app is not affected by the fact that deletion happens on the file system level after the 120 seconds delay. If that's true then I guess the patch doesn't fix the whole problem: When viewing a movie a second or third time kaffeine seems to close and try to reopen the file (which is gone if the 120 seconds have already passed so an error is thrown). There may be other apps that behave the same as kaffeine, and I don't think that behaviour is a bug per se. > When viewing a movie a second or third time [...]
I mean viewing several times from inside the started kaffeine instance, not by clicking the attachment in KMail repeatedly.
It's true that the patch in 130709 does not completely fix the problem, which is why it probably won't be implemented as is. We need a better solution. *** This bug has been marked as a duplicate of 130709 *** The "better solution" is to implement --tempfile in kaffeine so that it says "I handle the deletion of the tempfile myself" - after playing the movie as many times as it wants. With X-KDE-HasTempFileOption=true in its .desktop file, kaffeine can indicate that it supports the option, and then kmail/kioexec won't delete the file, kaffeine will. Reassigning to kaffeine proper --tempfile support is implemented in kaffeine svn thanks |