Progress Bar for the GNOME Media Notification
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 29 | Active |
| 28 | Active |
| 27 | Active |
| 26 | Active |
| 25 | Active |
| 24 | Active |
| 23 | Active |
| 22 | Rejected |
| 21 | Active |
| 20 | Active |
| 19 | Active |
| 18 | Active |
| 17 | Active |
| 16 | Active |
| 15 | Active |
| 14 | Inactive |
| 13 | Inactive |
| 12 | Inactive |
| 11 | Inactive |
| 10 | Inactive |
| 9 | Inactive |
| 8 | Rejected |
| 7 | Rejected |
| 6 | Inactive |
| 5 | Inactive |
| 4 | Inactive |
| 3 | Inactive |
| 2 | Inactive |
| 1 | Rejected |
Please avoid using unnecessary try and catch blocks.
This one is a bit complicated. A user had reported an issue that I wasn't able to reproduce consistently. I had pushed a commit that seemed to fix it on my end but they reported issues and tried to fix it themselves. The additional try catch ones were from that commit, and since I am unable to verify which ones fix the problem, I left them as a kind of blanket solution.
What's the user error in the logs?
The error reported was `Error: No signal connection undefined found`
Are you sure the dbus call is successful (line 231 `progressBar.js`)? Also, make sure the `this._busName` is correct in that call.
As per the freedesktop specs (https://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Method:SetPosition), the dbus call never seems to fail. It always says something along the lines of no effect. I don't think the issue is in that function though. Is there any significant performance issue with retaining the try catch statements? It only runs when destroy is called. I'll also be submitting a gnome 48 version with the same fixes.
Media Progress