grilo issueshttps://gitlab.gnome.org/GNOME/grilo/-/issues2021-10-06T11:57:44Zhttps://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/94Better handling behind portals2021-03-30T21:24:15ZBugzillaBetter handling behind portals## Submitted by Bastien Nocera `@hadess`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#769826)](https://bugzilla.gnome.org/show_bug.cgi?id=769826)**
## Description
In some cases, when behind flaky captive portals, the...## Submitted by Bastien Nocera `@hadess`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#769826)](https://bugzilla.gnome.org/show_bug.cgi?id=769826)**
## Description
In some cases, when behind flaky captive portals, the network might be "available" in GNetworkMonitor, but the HTTP calls would throw:
```
$ wget -Ofoo "http://thegamesdb.net/api/GetGamesList.php?name=Strider&platform=Sega%20Genesis"
--2016-08-13 14:22:18-- http://thegamesdb.net/api/GetGamesList.php?name=Strider&platform=Sega%20Genesis
Resolving thegamesdb.net (thegamesdb.net)... 104.27.146.170, 104.27.147.170, 2400:cb00:2048:1::681b:93aa, ...
Connecting to thegamesdb.net (thegamesdb.net)|104.27.146.170|:80... connected.
HTTP request sent, awaiting response... 302 Hotspot login required
Location: https://captive-portal.scc.kit.edu/login?dst=http%3A%2F%2Fthegamesdb.net%2Fapi%2FGetGamesList.php%3Fname%3DStrider%26platform%3DSega%2520Genesis [following]
--2016-08-13 14:22:18-- https://captive-portal.scc.kit.edu/login?dst=http%3A%2F%2Fthegamesdb.net%2Fapi%2FGetGamesList.php%3Fname%3DStrider%26platform%3DSega%2520Genesis
Resolving captive-portal.scc.kit.edu (captive-portal.scc.kit.edu)... 129.13.64.129
Connecting to captive-portal.scc.kit.edu (captive-portal.scc.kit.edu)|129.13.64.129|:443... connected.
HTTP request sent, awaiting response... 200 OK
```
First, we probably need to change the API used in GrlNet to actually care about HTTP statuses, and not just follow redirects and feed captive portals to grilo plugins.
The second part is that it might be nice to detect captive portals and propagate that state to the registry, so we hide sources that are not available.https://gitlab.gnome.org/GNOME/grilo/-/issues/59magnatune: Check for g_stat() retvals2018-09-24T09:32:56ZBugzillamagnatune: Check for g_stat() retvals## Submitted by Bastien Nocera `@hadess`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#749888)](https://bugzilla.gnome.org/show_bug.cgi?id=749888)**
## Description
The first use doesn't check the retval at all, and the ...## Submitted by Bastien Nocera `@hadess`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#749888)](https://bugzilla.gnome.org/show_bug.cgi?id=749888)**
## Description
The first use doesn't check the retval at all, and the other one runs g_file_test() when we've already run g_stat().
From coverity:
grilo-plugins-0.2.14/src/magnatune/grl-magnatune.c:566: check_return: Calling "stat(new_crc_path, &file_st)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.]
grilo-plugins-0.2.14/src/magnatune/grl-magnatune.c:561: check_return: Calling "stat(db_path, &file_st)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.]
Version: git masterhttps://gitlab.gnome.org/GNOME/grilo/-/issues/46tracker: Implement remove2021-03-30T21:46:27ZBugzillatracker: Implement remove## Submitted by Paolo Borelli `@pborelli`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#727363)](https://bugzilla.gnome.org/show_bug.cgi?id=727363)**
## Description
If you remove a video file externally (e.g through nau...## Submitted by Paolo Borelli `@pborelli`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#727363)](https://bugzilla.gnome.org/show_bug.cgi?id=727363)**
## Description
If you remove a video file externally (e.g through nautilus) and then you start totem, the file is still listed (not sure if it comes from recent files, or grilo or what).
When you select and remove it, the removal fails with no error reported on the UI and the following warning printed on the terminal
(totem:29369): Totem-WARNING **: Couldn't remove item 'foo.mp4' ((null)): Error trashing file: No such file or directoryhttps://gitlab.gnome.org/GNOME/grilo/-/issues/31Non-network plugins should have more priority2018-09-24T09:22:31ZBugzillaNon-network plugins should have more priority## Submitted by Juan A. Suárez Romero `@jasuarez`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#705562)](https://bugzilla.gnome.org/show_bug.cgi?id=705562)**
## Description
At this moment, all the plugins have the same ...## Submitted by Juan A. Suárez Romero `@jasuarez`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#705562)](https://bugzilla.gnome.org/show_bug.cgi?id=705562)**
## Description
At this moment, all the plugins have the same priority by default.
But when you have two different sources providing the same key, sources that don't require network connection should have more priority, as they would be faster.
As example, local-metadata and lastfm-albumart plugin both are able to return a "thumbnail" key, but have the same priority. So very easily we could use first lastfm-albumart instead of local-metadata source.
So the proposal is to add a default high priority to those plugins that don't require at all a network connection to work.
Version: git master