I’ve made a draft PR for this issue.
I have some general questions, that I’d rather ask here than polute the PR chat with it.
It’s stuck on testing, which I’d love to help with, now I that I finally have 2 setups (in WSL2 and on a Pi4) running with mopidy v4, on Ubunto 26.04 with Python 3.14.
Note that this is my 2nd PR ever! I’ve never worked on someone elses project. So I’m learning as I go.
I read the dvl guide. I got the git/github thing figured out, that is, forked, cloned, branched and pip installed in a venv. (I initially had copied the failing code right from mopidy into my extension…never mind).
Nick asked for tests, but that’s were I’m stuck. I’m sure it’s best if multiple people test this as it’s probably a Gst version specific thing and my fix impacts the audio scanning so if it fails…it may affect lots of people.
But what can I do to further test this myself?
I’ve got tox installed and it ran ok…I think…although a lot of deprecation warnings.
I also have my venv named differently, and tox complains about that (“venv .venv subdirectory not found in venv path /home/erik/programming/mopidy.”). Is that an issue?
That’s where I’m at.
I noticed the scan tests contains this function:
```python
def test_duration_is_set(self):
self.scan(self.find("scanner/simple"))
self.check_if_missing_plugin()
mp3 = path_to_data_dir("scanner/simple/song1.mp3")
assert self.result[mp3].duration == 4608
Should/could I perhaps write an extra test function that checks if the files songx.xxx are recognized as playable (assert self.result[...].playable == True?
Or should I leave this for the big kids 