GNOME Bugzilla – Bug 733780
Saving playlist state sometimes hangs totem
Last modified: 2018-05-24 10:57:27 UTC
Created attachment 281763 [details] $ GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:2 totem /home/mikhail/Videos/Загрузка.\ Подлинная\ история\ Интернета/Загрузка.\ Битва\ Браузеров.avi 2> log10 Demonstration part1: https://drive.google.com/file/d/0B0nwzlfiB4aQRk1vdzhxenFXZlU/edit?usp=sharing part2: https://drive.google.com/file/d/0B0nwzlfiB4aQQUNMYnh0TVVNTjA/edit?usp=sharing
Created attachment 281764 [details] kernel log
Can you please attach the output of a backtrace of the hang (run under gdb, when it's hung, press Ctrl+C in the gdb, and then "thread apply all bt"), and give the version of the GStreamer packages you're using?
This occurs every time when I try play video after OS boot.... Some time later this problem disappear Demonstration: https://drive.google.com/file/d/0B0nwzlfiB4aQcGpvb05vLWR1UHc/edit?usp=sharing
$ rpm -qa | grep gstreamer gstreamer1-plugins-ugly-1.2.4-1.fc20.x86_64 libnice-gstreamer1-0.1.4-2.fc20.x86_64 gstreamer-plugins-good-0.10.31-10.fc20.x86_64 gstreamer-0.10.36-6.fc20.i686 gstreamer-plugins-espeak-0.4.0-2.fc19.x86_64 gstreamer-0.10.36-6.fc20.x86_64 gstreamer-plugins-base-0.10.36-6.fc20.i686 gstreamer-plugin-crystalhd-3.10.0-6.fc20.x86_64 gstreamer1-1.2.4-1.fc20.x86_64 gstreamer-plugins-bad-free-0.10.23-20.fc20.x86_64 gstreamer1-plugins-bad-free-1.2.4-1.fc20.x86_64 gstreamer1-plugins-bad-freeworld-1.2.4-1.fc20.x86_64 gstreamer-plugins-ugly-0.10.19-14.fc20.x86_64 gstreamer1-libav-1.2.4-1.fc20.x86_64 gstreamer1-vaapi-0.5.8-3.fc20.x86_64 gstreamer1-plugins-base-1.2.4-1.fc20.x86_64 PackageKit-gstreamer-plugin-0.9.4-1.fc20.x86_64 gstreamer-plugins-base-0.10.36-6.fc20.x86_64 gstreamer1-plugins-good-1.2.4-2.fc20.x86_64 gstreamer-ffmpeg-0.10.13-12.fc20.x86_64 gstreamer-tools-0.10.36-6.fc20.x86_64
Can you please paste the backtrace as requested? And remove the gstreamer-plugin-crystalhd as well, it's known to cause problems.
Program received signal SIGINT, Interrupt. 0x00007ffff0492e9d in fsync () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) thread apply all bt
+ Trace 233937
Thread 1 (Thread 0x7ffff7fae9c0 (LWP 26908))
(gdb) (gdb) (gdb)
+ Trace 233938
(gdb) (gdb)
+ Trace 233939
Program received signal SIGINT, Interrupt. 0x00007ffff2b7aa22 in gdk_cairo_surface_paint_pixbuf (surface=surface@entry=0x7026910, pixbuf=pixbuf@entry=0x241bc00) at gdkcairo.c:242 242 MULT(q[1], p[1], p[3], t2); (gdb) thread apply all bt
+ Trace 233940
*** Bug 734860 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 734860 has been marked as a duplicate of this bug. *** Sorry, I am not sure that this backtrace are same.
(In reply to comment #11) > (In reply to comment #10) > > *** Bug 734860 has been marked as a duplicate of this bug. *** > > Sorry, I am not sure that this backtrace are same. It is, except the first hang in this bug. The first hang is Totem populating the recent view that's not visible when you launch it with a video, see bug 728716. The other ones are all hangs in totem_pl_parser_save().
You can work-around the problem by add a "return;" near the top of totem_playlist_save_session_playlist() in src/totem-playlist.c.
*** Bug 774988 has been marked as a duplicate of this bug. ***
*** Bug 788926 has been marked as a duplicate of this bug. ***
Created attachment 361928 [details] [review] 0001-Avoid-fsync-that-causes-totem-hangs-stutter.patch Here's a fix (for totem-pl-parser). Some might call it a compromise but I felt that solutions involving threading were a messy overkill.
Review of attachment 361928 [details] [review]: I think this is fine at app level, as a better long term fix, what about not adding a G_FILE_CREATE_DELETE_FIRST (or better naming) to do this when is set? As per comment on code requesting the sync: /* If the final destination exists, we want to sync the newly written * file to ensure the data is on disk when we rename over the destination. * otherwise if we get a system crash we can lose both the new and the * old file on some filesystems. (I.E. those that don't guarantee the * data is written to the disk before the metadata.) */ It would probably nice to do this depending on the filesystem in use anyway.
A G_FILE_CREATE_DELETE_FIRST would be unacceptable because it breaks the designed and documented robustness of g_file_replace... https://developer.gnome.org/gio/stable/GFile.html#g-file-replace So it's only appropriate to break that robustness on a per-app basis.
Review of attachment 361928 [details] [review]: There's 2 ways of working around this. Either: - adding an async version of totem_pl_parser_save(), which would populate an internal buffer in the main thread, and save it async'ly - add a way to save to memory, and dump the file to disk in totem itself, where we can apply any work-arounds that would be good enough for the purpose, without breaking the reliability of saves for other library users Marco, you're not a totem or totem-pl-parser developer, you have no authority to set patches to "accepted commit now". At best, you can review the patches and set them as "reviewed" or "needs-work" as a first pass review.
I count at least 4 ways. The 2 you mention, plus: - What I proposed above: Just delete the file first. A one line fix. - Background the offending g_object_unref in a thread. And ensure it's finished before the next time round. There shouldn't be much contention in reality since it takes less than a second to complete and we only attempt it once every 10 seconds. Since you seem to be leaning toward solutions that require API changes, I think we might just go with my above patch in Ubuntu for now. Although both options I've mentioned here avoid API changes across the project boundary.
For the benefit of anyone else suffering from this, a workaround is: rm ~/.config/totem/session_state.xspf touch ~/.config/totem/session_state.xspf sudo chattr +i ~/.config/totem/session_state.xspf The side effect is that Totem will no-longer resume a video when restarted from where it left off, but, for me, that’s a small price to pay for smooth playback.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/totem/issues/116.