On Tue, 2013-05-28 at 14:51 +0200, Roland Peffer wrote: > Well, > > till now I only used the diskussed approach for resolving url data > from vimeo or youtube , as these are not included in the fast keys and > at least vimeo > had a blocking call in libquvi. > > Regarding the operation cancelation I also tried to run grl_browse in > a seperate thread with a new GMainContext, and it worked except the > gdata libe under grl-youtube made trouble from time to time. Not on > cancelation , but on next browsing after a cancelation. > > Just I have no time right now to get deeper into this. > Anyway it would be nice to have a solution to let grilo run in a > seperate thread outside of the default main context.
The correct way to fix this isn't to make grilo callbacks run in a separate thread, but to make them not block. So the quvi calls shouldn't be made in grilo synchronously, but asynchronously. One way you can achieve that is by using totem-pl-parser. You'd do: if (!totem_pl_parser_can_parse_from_uri(uri, FALSE)) /* return error */ totem_pl_parser_parse_async (parser, uri, FALSE, ....) and emit the end of the grilo lookup operation from the callback. totem-pl-parser is already used by grilo itself, and could be used in plugins that require quvi support. See the documentation for more info: https://developer.gnome.org/totem-pl-parser/stable/TotemPlParser.html Cheers _______________________________________________ grilo-list mailing list grilo-list@gnome.org https://mail.gnome.org/mailman/listinfo/grilo-list
