Conversation
Signal handling is not yet done.
99870f0
to
20414da
Compare
This gets rid of all threading (except the one in gstreamer itself, which is not exposed to the consuming code).
https://bugreports.qt.io/browse/QTBUG-93405 is making everything more complicated, but let's optimize signal emission later.
This greatly reduces the number of signals emitted on D-Bus.
Now we always know that we have a player bound to it.
Remove a couple of entries which change dynamically and cause frequent emissions of the PropertiesChanged signal: https://bugs.launchpad.net/ubuntu/+source/media-hub/+bug/1598799 These properties are not part of the spec and are not read by other processes anyway.
This will allow upstart (or systemd) to restart our service.
This was unused even in the original version.
This is only testing the gstreamer engine: we'll test it in the functional tests.
These files were all unused. Let's start from scratch.
They'll not be used by the client.
This is hardly relevant here, and removing it can make the tests run a bit faster.
This can confuse the client.
Clients wishing to play alert sounds (such as unity8 when taking a screenshot) need to set this in order not to stop the media player.
If the server is not closed, tests fail in CI.
Set the context object so that the signal will be automatically disconnected when the object dies.
For some reason sometimes using localhost fails in my local machine, whereas the numeric address always works.
Let's still keep the URL-based detection for a while, until we fix the client library as well.
awesome work. how to test for remote media ? |
Confirmed it fix #24 :) |
You could try MiTubo; here's a very old click, let me know if you need arm64. I'll upload it to the store after the new media-hub gets released into some OTA. |
@mardy , humm , had no luck to build mitubo project with clickable version 6.24.1
|
I'll investigate why this happens. Meanwhile, please use |
@mardy well, same with 6.23.3, also the link provided for the click does not work here (http://mardy.it/archivos/tmp/it.mardy.mitubo_0.1-0_armhf.click) |
don't know if related but audio recording and playback doesn't work on messaging app: Recording:
PlayBack:
|
In both cases, it looks like media-hub is not running (it might have crashed, maybe?). Can you please reproduce it while collecting the bustle logs ( |
@mardy here is some logs: Recording audio:
PlayBack audio:
|
Thanks @lduboeuf , it's great that you found this issue before we merged this! So, there are actually two issues
Inspecting the file from the terminal gives a similar result:
So I think I'll just hack around this and consider the mime type |
This fixes a crash when receiving a label like "messaging-app (enforce)".
These files are detected as having a video/3gpp MIME type. Since we know that they are audio files, let's make a little hack.
Both should be fixed now, please try the latest media-hub: https://ci.ubports.com/blue/organizations/jenkins/ubports%2Fmedia-hub/detail/PR-28/30/artifacts/ |
@mardy confirm it works with messaging app 👌 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've run the Canonical test plans and run many apps which test the sound system. I think we're ready to go.
This is now ready for review. I've tested a few use cases, and everything seems to work fine. Playing remote media also works.
I've removed the unit tests, which were not testing much anyway, and replaced them with functional tests where the whole media-hub-server component is run in a standalone D-Bus session where all dependent services (like powerd, the power indicator, telepathy) are mocked.
Fixes: #29
Fixes: #24