grilo issueshttps://gitlab.gnome.org/GNOME/grilo/-/issues2024-03-06T03:40:21Zhttps://gitlab.gnome.org/GNOME/grilo/-/issues/156Use lists instead of `browse`2024-03-06T03:40:21ZShema Angelo VerlainUse lists instead of `browse`I'm not quite sure about this yet. But it would be nice if, instead of passing a callback to `browse`, that method could return a `GioListModel`.
Because `GioListModel` is an easily extendable interface, one can easily listen for change...I'm not quite sure about this yet. But it would be nice if, instead of passing a callback to `browse`, that method could return a `GioListModel`.
Because `GioListModel` is an easily extendable interface, one can easily listen for changes in the list (such as when the API returns more items later on...). We can even go crazy and implement pagination with that by attaching methods like `query_next()` or `query_previous()` if the implementation supports them...
overkill: It would also be possible to add properties like `loading` that will be updated by the plugin when the list has finished loading.https://gitlab.gnome.org/GNOME/grilo/-/issues/155Allow registering plugins using an API2024-03-06T03:35:23ZShema Angelo VerlainAllow registering plugins using an APIIt's complicated to register plugins from non-C languages. Mainly because the function macro used is `G_PLUGIN_DEFINE`, and C function macros aren't exposed as introspected functions. The above issue could be solved by using the properti...It's complicated to register plugins from non-C languages. Mainly because the function macro used is `G_PLUGIN_DEFINE`, and C function macros aren't exposed as introspected functions. The above issue could be solved by using the properties in `GrlPluginDescriptor` as construct-only parameters for `GrlPlugin`.
For example, here's how it would work in JavaScript.
```js
const plugin = new Grl.Plugin({
id: "hello.world.com",
name: "MyPlugin",
// ...
});
Grl.Registry.register_plugin(plugin);
```
Here are the pieces that are currently missing:
1. It's not currently possible to directly set the properties of a plugin like `id`, `name`, `license`, etc... Grilo expects all plugins to be modules. To fix this, I propose that the properties of `GrlPluginDescriptor` be allowed for `GrlPlugin` as **construct-only** properties. This way, plugins can be defined in non-C environments.
2. There is no way to register a plugin when you've defined it (`Grl.Registry.register_plugin`). Similar to `Grl.Registry.load_plugin_from_desc`, but that function is not available for language bindings.https://gitlab.gnome.org/GNOME/grilo/-/issues/154D-Bus adaptor2024-03-06T03:29:25ZShema Angelo VerlainD-Bus adaptorWhile we can create Grilo plugins easily in C. It's much harder to create them in other languages. This is because plugins are expected to be installed in a specific directory and loaded with `GModule`, which is only compatible with C.
...While we can create Grilo plugins easily in C. It's much harder to create them in other languages. This is because plugins are expected to be installed in a specific directory and loaded with `GModule`, which is only compatible with C.
A solution I imagined would be to create something like a D-Bus adaptor that takes a plugin and exposes it via a D-Bus interface by creating a _server_.
On the application side, we can use said plugin easily by using the D-Bus adaptor and connecting to the exposed D-Bus interface. This would, of course, require that all data be serializable which I don't know if it's true.
Here's some pseudocode to demonstrate my ideas:
```c
plugin = grilo_plugin_new();
plugin.id = "com.vixalien.grilo-plugin"
// setup plugin
grilo_dbus_expose(plugin, "com.vixalien.grilo-plugin")
// exposed at somewhere like /org/gnome/Grilo/plugins/com.vixalien.grilo-plugin
// in my application
plugin = grilo_dbus_connect("com.vixalien.grilo-plugin")
// use the plugin
```https://gitlab.gnome.org/GNOME/grilo/-/issues/153Expose GrlMedia properties2024-03-06T03:22:22ZShema Angelo VerlainExpose GrlMedia properties`GrlMedia` has a lot of "properties": `artist`, `director`, `genre`, `lyrics`, etc..
However, to use them, we must use methods like `grl_media_set_artist`, `grl_media_add_artist`, `grl_media_get_artist` etc... While these are incredibly...`GrlMedia` has a lot of "properties": `artist`, `director`, `genre`, `lyrics`, etc..
However, to use them, we must use methods like `grl_media_set_artist`, `grl_media_add_artist`, `grl_media_get_artist` etc... While these are incredibly convenient for C, properties are more useful for object-oriented languages like Python and JavaScript.
Now, I believe it would be relatively straightforward to add all those properties with a helper function. Still, the issue I can see is that some properties also expect multiple values (like artist, director, etc..)
I'm not sure how to handle this, but maybe there could be 2 different properties:
- `artist`: which returns one artist (presumably the first one)
- `artists`: return a `GList` (or GSList or whatever) as those are automatically mapped to arrays in object oriented languages.https://gitlab.gnome.org/GNOME/grilo/-/issues/152[Doc] Some types need migration2024-03-06T03:01:46ZShema Angelo Verlain[Doc] Some types need migrationAfter #100, Grilo will use `gi-docgen` instead of `gtk-doc` for documentation. However, the generated documentation are not perfect because of the incompatibility between the doc formats. Here are some of the issues I found in need of im...After #100, Grilo will use `gi-docgen` instead of `gtk-doc` for documentation. However, the generated documentation are not perfect because of the incompatibility between the doc formats. Here are some of the issues I found in need of improvement.
* Some structs (like [`GrlPluginDescriptor`](https://grilo-vixalien-5f494c25a44ca4985849bea066d2a7d8d0692b89489d1228.pages.gitlab.gnome.org/struct.PluginDescriptor.html) are missing type annotations.
* Functions that return lists like `Grl.Data.get_keys` don't correctly annotate their return types, leading to documentation that seems redundant, like in the case mentioned above:https://gitlab.gnome.org/GNOME/grilo/-/issues/151Please tag a new release with libsoup-3.0 fixes2023-05-09T11:53:55ZMatt TurnerPlease tag a new release with libsoup-3.0 fixesgrilo and grilo-plugins v0.3.15 are unshippable in their current state if the distro wants to enable libsoup-3 support. E.g. grilo fails to configure with
> meson.build:164:16: ERROR: Problem encountered: Missing dependencies for dmap p...grilo and grilo-plugins v0.3.15 are unshippable in their current state if the distro wants to enable libsoup-3 support. E.g. grilo fails to configure with
> meson.build:164:16: ERROR: Problem encountered: Missing dependencies for dmap plugin
because it incorrectly looks for libdmapsharing-3.0. This was fixed in master, but over the course of multiple patches, and those patches require patches in grilo (https://gitlab.gnome.org/GNOME/grilo/-/merge_requests/95) that are also not in a release.
It would be awesome if grilo and grilo-plugins were parallel-installable with libsoup-2.4 and libsoup-3.0 versions. As it is, the current situation is sort of a disaster with some consumers of grilo/grilo-plugins relying on libsoup-2.4 (e.g. [pragha](https://github.com/pragha-music-player/pragha) and [rhythmbox](https://gitlab.gnome.org/GNOME/rhythmbox) require libsoup-2.4 but [gnome-music](https://gitlab.gnome.org/GNOME/gnome-music) requires libsoup-3.0).
Cc: @victortoso, @mcatanzarohttps://gitlab.gnome.org/GNOME/grilo/-/issues/150Operation Options: Do not remove default range values2021-10-06T11:57:44ZVictor Tosovictortoso@gnome.orgOperation Options: Do not remove default range valuesFound with code inspection this two problems:
1) In case max_value and min_value are NULL, we remove the range data from the HashTable here: [g_hash_table_remove in L737](https://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grl-operat...Found with code inspection this two problems:
1) In case max_value and min_value are NULL, we remove the range data from the HashTable here: [g_hash_table_remove in L737](https://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grl-operation-options.c#L737)
2) In case either max_value or min_value are NULL, we might be resetting the default value in here: [grl_range_value_hashtable_insert in L757](https://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grl-operation-options.c#L757)https://gitlab.gnome.org/GNOME/grilo/-/issues/149Operation Options: On init, initialize range values2021-10-06T11:49:48ZVictor Tosovictortoso@gnome.orgOperation Options: On init, initialize range valuesIt seems that Grilo is not populating the [_key_range_filter_](https://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grl-operation-options.c#L43) with GParamSpec values of default keys like [_orientation_](https://gitlab.gnome.org/GNOME...It seems that Grilo is not populating the [_key_range_filter_](https://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grl-operation-options.c#L43) with GParamSpec values of default keys like [_orientation_](https://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grl-metadata-key.c#L422).
This needs to be confirmed and fixed, with a test under tests/operations.c :)https://gitlab.gnome.org/GNOME/grilo/-/issues/148Warning caused by tracker usage2022-12-05T10:53:16ZBastien NoceraWarning caused by tracker usageWith grilo and grilo-plugins 0.3.14
```
(totem:55): GLib-GObject-CRITICAL **: 11:35:15.507: g_param_values_cmp: assertion 'G_IS_VALUE (value1)' failed
```
```
#0 0x00007ffff7def2ea in g_logv () at /usr/lib/x86_64-linux-gnu/libglib-2.0...With grilo and grilo-plugins 0.3.14
```
(totem:55): GLib-GObject-CRITICAL **: 11:35:15.507: g_param_values_cmp: assertion 'G_IS_VALUE (value1)' failed
```
```
#0 0x00007ffff7def2ea in g_logv () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff7def5a3 in g_log () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7ef05ba in g_param_values_cmp () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3 0x00007ffff65bdad3 in () at /app/lib/libgrilo-0.3.so.0
#4 0x00007ffff65b75ac in grl_operation_options_set_key_range_filter_value () at /app/lib/libgrilo-0.3.so.0
#5 0x00007ffff65b7847 in grl_operation_options_set_key_range_filter () at /app/lib/libgrilo-0.3.so.0
#6 0x00007ffff7f5eafc in browse (self=0x55555574e8a0, model=0x555555d27930, path=0x0, source=0x55555664d4f0, container=0x0, page=-1) at ../src/totem-grilo.c:764
#7 0x00007ffff7f61e7b in source_added_cb (registry=<optimized out>, source=0x55555664d4f0, user_data=<optimized out>) at ../src/totem-grilo.c:1337
#8 0x00007ffff7ee3fef in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff7ef6e66 in signal_emit_unlocked_R () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff7efdb5c in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff7efdcb3 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007ffff65bb115 in grl_registry_register_source () at /app/lib/libgrilo-0.3.so.0
#13 0x00007ffff0024b30 in grl_tracker_source_sources_init () at /app/lib/grilo-0.3/libgrltracker3.so
#14 0x00007ffff0025f19 in () at /app/lib/grilo-0.3/libgrltracker3.so
#15 0x00007ffff7c57dc9 in g_task_return_now () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#16 0x00007ffff7c589bb in g_task_return () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#17 0x00007ffff601ff16 in () at /app/lib/libtracker-sparql-3.0.so.0
#18 0x00007ffff7c57dc9 in g_task_return_now () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#19 0x00007ffff7c57e0d in complete_in_idle_cb () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#20 0x00007ffff7de7681 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007ffff7de7b68 in g_main_context_iterate.constprop () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff7de7c33 in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff7c87c65 in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#24 0x0000555555556394 in main (argc=<optimized out>, argv=<optimized out>) at ../src/totem.c:83
```
The code in totem:
```C
if (grl_caps_is_key_range_filter (caps, GRL_METADATA_KEY_DURATION))
grl_operation_options_set_key_range_filter (default_options,
GRL_METADATA_KEY_DURATION, MIN_DURATION, MAX_DURATION,
NULL);
```https://gitlab.gnome.org/GNOME/grilo/-/issues/147Compilation fails with grlnet disabled2021-10-04T13:56:30ZBastien NoceraCompilation fails with grlnet disabled```
../bindings/vala/meson.build:8:0: ERROR: Unknown variable "grlnet_gir".
``````
../bindings/vala/meson.build:8:0: ERROR: Unknown variable "grlnet_gir".
```https://gitlab.gnome.org/GNOME/grilo/-/issues/146(CVE-2021-39365) Missing TLS certificate verification2021-08-22T21:38:48ZMichael Catanzaro(CVE-2021-39365) Missing TLS certificate verificationHi, grl-net-wc.c does not appear to be enabling TLS certificate verification on the SoupSessionAsync object it creates. Same problem as libgrss#4. [You have to do this manually when using the deprecated SoupSessionAsync.](https://blogs.g...Hi, grl-net-wc.c does not appear to be enabling TLS certificate verification on the SoupSessionAsync object it creates. Same problem as libgrss#4. [You have to do this manually when using the deprecated SoupSessionAsync.](https://blogs.gnome.org/mcatanzaro/2021/05/25/reminder-soupsessionsync-and-soupsessionasync-default-to-no-tls-certificate-verification/)2021-08-23https://gitlab.gnome.org/GNOME/grilo/-/issues/145Understanding GrlMedia and GrlRelatedKeys (and fixing?)2021-05-07T21:07:13ZVictor Tosovictortoso@gnome.orgUnderstanding GrlMedia and GrlRelatedKeys (and fixing?)So, GrlRelatedKeys should be a way to combine metadata-keys that don't make much sense together or might be specific to that subset of metadata-keys, my main problem is when both of them are around at the same time, for instance:
```jso...So, GrlRelatedKeys should be a way to combine metadata-keys that don't make much sense together or might be specific to that subset of metadata-keys, my main problem is when both of them are around at the same time, for instance:
```json
{
"artist" : "Queen",
"grl-related-keys" : [
{
"artist" : "Freddie Mercury",
"mb-artist-id" : "022589ac-7177-460d-a178-9976cf70e29f",
}, {
"artist" : "Roger Taylor",
"mb-artist-id" : "558302b1-07ae-4be1-9edb-2a2b1f036313",
}, {
"artist" : "Brian May",
"mb-artist-id" : "6d24f102-5c43-453a-8664-4ee092f441cf",
}
]
}
```
I created a small test function that shows what I mean. In the end, I would like that "artist"="Queen" metadata-key in GrlMedia would not be related at all to created GrlRelatedKeys.
The test file that I mentioned [is here](https://gitlab.gnome.org/victortoso/grilo/-/blob/media-related-keys/tests/media.c#L229), copying it below:
```c
/* This test checks that Grilo API gives the right value for the amount of
* metadata-keys when is used together with GrlRelatedKeys
*/
static void
test_length_of_metadata_keys (void)
{
GrlMedia *media;
GrlRelatedKeys *relkeys;
GList *single_keys;
media = grl_media_audio_new();
relkeys = grl_related_keys_new_with_keys (
GRL_METADATA_KEY_ARTIST, "Freddie Mercury",
GRL_METADATA_KEY_MB_ARTIST_ID, "022589ac-7177-460d-a178-9976cf70e29f", NULL);
grl_data_add_related_keys (GRL_DATA (media), relkeys);
g_assert_cmpuint (1, ==, grl_data_length (GRL_DATA (media), GRL_METADATA_KEY_ARTIST));
g_assert_cmpstr ("Freddie Mercury", ==, grl_media_get_artist_nth (media, 0));
relkeys = grl_related_keys_new_with_keys (
GRL_METADATA_KEY_ARTIST, "Roger Taylor",
GRL_METADATA_KEY_MB_ARTIST_ID, "558302b1-07ae-4be1-9edb-2a2b1f036313", NULL);
grl_data_add_related_keys (GRL_DATA (media), relkeys);
g_assert_cmpuint (2, ==, grl_data_length (GRL_DATA (media), GRL_METADATA_KEY_ARTIST));
g_assert_cmpstr ("Roger Taylor", ==, grl_media_get_artist_nth (media, 1));
relkeys = grl_related_keys_new_with_keys (
GRL_METADATA_KEY_ARTIST, "Brian May",
GRL_METADATA_KEY_MB_ARTIST_ID, "6d24f102-5c43-453a-8664-4ee092f441cf", NULL);
grl_data_add_related_keys (GRL_DATA (media), relkeys);
g_assert_cmpuint (3, ==, grl_data_length (GRL_DATA (media), GRL_METADATA_KEY_ARTIST));
g_assert_cmpstr ("Brian May", ==, grl_media_get_artist_nth (media, 2));
/* FIXME:
* Set 'Queen' bellow resets the value of related-key index 0. We lost Freddie!!!
* It *should* be a *single* key not associated with a related key. This means that
* grl_data_length () should return 4 instead of 3.
*/
grl_media_set_artist (media, "Queen");
g_assert_cmpuint (4, !=, grl_data_length (GRL_DATA (media), GRL_METADATA_KEY_ARTIST));
g_assert_cmpstr ("Freddie Mercury", !=, grl_media_get_artist_nth (media, 0));
/* Note that add works as adding in the GrlRelatedKeys section. Should not!
* We could have the case where we add a list of values of a given
* metadata-key and not necessarily it would be related to this
* metadata-key in an GrlRelatedkey in the same GrlMedia
*/
grl_media_add_artist (media, "King");
g_assert_cmpuint (4, ==, grl_data_length (GRL_DATA (media), GRL_METADATA_KEY_ARTIST));
g_assert_cmpstr ("King", ==, grl_media_get_artist_nth (media, 3));
/* FIXME: This is yet another bug as the documentation explicity says `ignores related-keys` */
single_keys = grl_data_get_single_values_for_key (GRL_DATA (media), GRL_METADATA_KEY_ARTIST);
g_assert_cmpuint (4, ==, g_list_length (single_keys));
g_list_free (single_keys);
}
```
Please, let me know if the problem is clear and if both FIXME above make sense to you. I plan to address this soon as this blocks some [other work](https://gitlab.gnome.org/victortoso/grilo/-/commits/serialize-json) that I'm doing.grilo-futurehttps://gitlab.gnome.org/GNOME/grilo/-/issues/144search callback can return negative value for reamining parameter2021-03-19T19:02:56ZChristian Hergertsearch callback can return negative value for reamining parameterThe type of the parameter is `guint`, yet I'm seeing -1 (0xffffffff) for the callback in some situations.The type of the parameter is `guint`, yet I'm seeing -1 (0xffffffff) for the callback in some situations.https://gitlab.gnome.org/GNOME/grilo/-/issues/143[Feature Request] Add support for Jellyfin2022-08-12T07:18:50ZSaroufim[Feature Request] Add support for JellyfinJellyfin support would be quite useful for Totem and gnome-music.Jellyfin support would be quite useful for Totem and gnome-music.https://gitlab.gnome.org/GNOME/grilo/-/issues/142Migration of grilo-list to GNOME Discourse instance2021-03-21T21:38:26ZOlav VittersMigration of grilo-list to GNOME Discourse instanceHello,
I'm creating this issue for the owner of the mailing list https://mail.gnome.org/archives/grilo-list/.
We've set up https://discourse.gnome.org a year and a half ago, as part of an attempt at making the GTK mailing list more fri...Hello,
I'm creating this issue for the owner of the mailing list https://mail.gnome.org/archives/grilo-list/.
We've set up https://discourse.gnome.org a year and a half ago, as part of an attempt at making the GTK mailing list more friendly to newcomers. This experiment seems to have proven itself well enough, and has since expanded to other territories as well. As such, we believe it is time to make the same switch for most of our mailing lists. The discussion around the move is held at https://gitlab.gnome.org/GNOME/Initiatives/-/issues/18 .
This means that the https://mail.gnome.org/archives/grilo-list/ mailing list will be archived in favour of continued discussion at GNOME's Discourse instance. No need to worry that this will mess with your workflow: it is still possible to get notifications by email by subscribing to the appropriate tags and/or posts. You can also still reply by e-mail if you prefer. Just like before, it's also possible to receive a general weekly digest.
The proposed closure of this mailing list will be on: Oct 30th, 2020 (or earlier if acceptable by you)
As a subscriber of this mailing list please create an account on https://discourse.gnome.org/. It's unfortunately not possible to automatically migrate the existing subscribers to Discourse. In case you wonder what will happen to the current mailing list after the closure date: the archives will remain public though you won't be able to subscribe or send emails to the current list.
For https://mail.gnome.org/archives/grilo-list/ the new discussions would take place in the Platform (right? or Applications?) category on Discourse using the (to be created) 'grilo' tag.
For further information on Discourse, please see the following topics:
* https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
* https://discourse.gnome.org/t/tags-and-watching/94
Do you agree with moving the list over to Discouse?
On behalf of the Discourse migration volunteers.
Cheers, Olav2020-10-30https://gitlab.gnome.org/GNOME/grilo/-/issues/141Crash when using get_plugins bindings2020-07-29T07:57:09ZMarinus Schraalmschraal@gnome.orgCrash when using get_plugins bindingsThis usage of registry `get_plugins` segfaults: [grilo-test.py](/uploads/e1e16b699709c3ed6e9859fce8b10087/grilo-test.py).
Backtrace: [gdb.txt](/uploads/2662c37d02dfdb687a7705af194e4a67/gdb.txt)
The same thing in C works fine: [grilo-te...This usage of registry `get_plugins` segfaults: [grilo-test.py](/uploads/e1e16b699709c3ed6e9859fce8b10087/grilo-test.py).
Backtrace: [gdb.txt](/uploads/2662c37d02dfdb687a7705af194e4a67/gdb.txt)
The same thing in C works fine: [grilo-test.c](/uploads/ee5f84b098cf52edfe54d683f9c79364/grilo-test.c).
!60 fixes the issue. However, from the looks of it this should ideally not be needed. I do not see anything obviously wrong with the annotations though.https://gitlab.gnome.org/GNOME/grilo/-/issues/140API inconsistency in grl_operation_options_set_key_range_filter()2023-01-02T06:27:55ZCarlos GarnachoAPI inconsistency in grl_operation_options_set_key_range_filter()The `grl_operation_options_set_key_range_filter()` function is a varargs method that takes various types, the API documentation of `grl_operation_options_set_key_range_filter()` says `The range can be open if some of the minX, maxX value...The `grl_operation_options_set_key_range_filter()` function is a varargs method that takes various types, the API documentation of `grl_operation_options_set_key_range_filter()` says `The range can be open if some of the minX, maxX values are NULL.`, documented with this example:
```
grl_operation_options_set_key_range_filters (my_options,
GRL_METADATA_KEY_ALBUM, "Ta", "Tz",
GRL_METADATA_KEY_BITRATE, 256, NULL,
NULL);
```
This seems troublesome to advise for non-pointer types, as we are passing a pointer-sized argument, but maybe reading it on the other side with a lesser width (eg. 32bit int), this seems a sure way to confuse the va_args machinery. It also results in those values being mistakenly interpreted (e.g. set to 0 in the example above), which cannot be handled consistently in the plugin side.
Given the code cannot handle pointer-sized arguments in places where it eg. expects an int for this to work, I'd say it's easier to consider this a documentation bug, and change it so it's advised to specify both limits in this varargs function.
This is a small thing I noticed in the doing of https://gitlab.gnome.org/GNOME/grilo-plugins/-/merge_requests/85, totem sets a minimum duration filter this way and it currently breaks by capping the maximum duration to NULL (which turns out 0).https://gitlab.gnome.org/GNOME/grilo/-/issues/139grl_init() has wrong annotations2020-04-08T17:36:12ZAlice Mikhaylenkogrl_init() has wrong annotationshttps://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grilo.c#L145
`argv` shouldn't be `transfer none` as it gets modified. This causes it to have `ref unowned string[]? argv` parameter in Vala.
CC @ricotzhttps://gitlab.gnome.org/GNOME/grilo/-/blob/master/src/grilo.c#L145
`argv` shouldn't be `transfer none` as it gets modified. This causes it to have `ref unowned string[]? argv` parameter in Vala.
CC @ricotzhttps://gitlab.gnome.org/GNOME/grilo/-/issues/138Release please2020-01-09T14:14:52ZMichael CatanzaroRelease pleaseWe need a new release for https://gitlab.gnome.org/GNOME/grilo/commit/60d135ef64f16671bb0ab4079ecbc59bdc32cbc7We need a new release for https://gitlab.gnome.org/GNOME/grilo/commit/60d135ef64f16671bb0ab4079ecbc59bdc32cbc7Jordan PetridisJordan Petridis2020-01-04https://gitlab.gnome.org/GNOME/grilo/-/issues/137Add Chromaprint Property to Grilo2019-07-15T10:04:24ZSumaidAdd Chromaprint Property to GriloWe need to store the chromaprint of songs in the tracker database to avoid the expensive calculation of chromaprinting again and again.
Add support for Chromaprint property in GriloWe need to store the chromaprint of songs in the tracker database to avoid the expensive calculation of chromaprinting again and again.
Add support for Chromaprint property in Grilo