[weboob] How to browse videos in batch?
guilhem.bonnefille at gmail.com
Mon May 5 13:49:16 CEST 2014
2014-05-05 9:20 GMT+02:00 Romain Bignon <romain at symlink.me>:
> On 05/May - 08:52, Guilhem Bonnefille wrote:
>> I'm a new weboob user. Recently, I hacked a Gnome-shell extension in
>> order to have videoob search results directly in the Gnome-shell
> Yes, we came upon this, it is nice (but it makes little freezes during
Yes. I think I have to find the way to read videoob result
asynchronously. The same occurs with my new project as I'm unable to
find a (easy) way to read videoob result without locking main thread.
>> A realized that this integration is probably not so useful. So, I
>> decided to hack in an other way: integrate weboob multimedia features
>> in totem. With recent version of totem, this seems to request hacking
>> grilo. So I started a grilo-plugin:
>> For this hack, I decided to use raw C, so development is quite long
>> and hard. But I think I will have something working in few days.
>> In order to simplify, currently I'm running a videoob process each
>> time I need an information. But as I'm new to weboob, I'm not able to
>> find the more effective command lines.
> There is a POC application that shares weboob commands in dbus. I don't know if
> it is a more efficient, as it needs to have a daemon launched all the time, but
> that's an alternative.
This could be an alternative.
An other one could be to run an interactive instance of videoob: send
command and read result. But this is quite complex.
A last one could be to load the weboob python library and use a wrapper.
I'm currently unable to evaluate which one is the simplest.
>> For example, in order to search for videos, I first launch a "videoob
>> search" and then parse the result. I realized that this output does
>> not contain the URL of the real media. I think I need to run a
>> "videoob info" in order to retrieve full information about a video.
>> Why such behavior? Is there a way to obtain full informations in a
>> single request? Is this last solution more time consuming?
>> I think it is not a really big problem as grilo seems to act in a
>> similar way: a search pass is quite fast and a resolve pass allow
>> plugin to improve search result.
> Default behavior only returns fields that are easily found, so as the direct URL
> of videos aren't present in search results pages, it is not filled by default.
> You can force it by passing the --select parameter. In your case, it should be
> "-s url" to get url. You can also give "-s \$full" to fill all possible fields.
> Of course, asking videoob to fetch all available fields will take more time.
OK, thanks. I will keep the efficient design: providing only available
data after a search and expecting a request from grilo to resolve
>> Another example of misunderstanding is the way to "browse" a video provider.
>> I discovered that "videoob ls" allow to have all feeds from all
>> activated backend. Next, "videoob ls arte-live" allow to browse
>> content of "arte-live" pseudo-directory. But I did not find how to
>> browse content of a subdirectory: "videoob ls arte-live/1" does not
>> work. At the same time, I found a possible solution: "videoob cd
>> arte-live \; cd 1 \; ls" give a potential result.
>> Is it the only way to do this request? Is there a simpler solution?
> Yes, this is a limitation of the "ls" command of console applications. I think
> we should enhance that.
Ideally a design following the classic path logic could be useful
An other solution could be to provide a widelly uniq identifier for
subdirs: instead of '1' return '1 at arte-live' or something like that
(not relly different than providing the path logic).
-=- JID: guyou at im.apinc.org MSN: guilhem_bonnefille at hotmail.com
-=- mailto:guilhem.bonnefille at gmail.com
More information about the weboob