New to the community, so I hope I’m putting this in the right place.
I’ve had a Picroft running on a Pi 4 for about a month now, and I am impressed at its capabilities. One issue I am struggling with is the Emby skill, which I use to control media playback. I had it all working about the same time I initially set it up, but something happened somewhere and now nothing plays. Mycroft picks up on the fact that I want a song to be played from Emby, and responds back with “playing [song name]”.
Also, quick side note: I reflashed the SD card with the unstable version of mycroft because the stable one was throwing errors at me. That’s its own post though. Unstable version works just fine from the brief tests I’ve done. Anyway, back to the main point.
The other log files (enclosure, skills, bus, voice) didn’t show any errors. I really wish I could narrow down the problem to my Emby configuration or my Mycroft configuration, but I don’t know how to do that. The closest I can do is play music from Emby to my computer via the WebUI, which works just fine by the way.
When you say it worked previously, was this on the same device and the same Skill settings? Or is this a new install.
A common issue I’ve seen is that the Emby settings expect the protocol to be included in the host eg: 192.168.1.10
^^ won’t work
it needs to be: http://192.168.1.10
Would be good to post the output of your skills.log to see whether it’s querying emby at all.
Thanks for the response. I tried changing the server URL field in the skills field for my Emby server, and it now gives a different error. New audio.log output.
However, skills.log may reveal the root of the issue, which is a lack of an internet connection. This doesn’t make a lot of sense though, because I can ssh into the Pi just fine, and the Emby server is on the same network as the Pi. Same subnet and on the same switch. Why would mycroft need to connect to the internet for a server on the local network? skills.log output
I am running the unstable version right now because the stable version was not stable for me, but I’ll give it another go if necessary.
Update: I change the configuration to use Emby’d IP address by itself instead of adding http:// to the front of it, and now I get a different issue. Picroft is now able to connect to the Emby server and pick up the track, but the song never plays.
pactl list sink-inputs (if using PulseAudio) is always a good thing while playing to see if something gets applied (eg. a filter) to that stream. Especially when nothing is visibly wrong.
You can start the cli in debug mode, yet i don’t think this is helpful when audio issues are involved.
(as a general suggestion mycroft could put out an excerpt - media.role/media.name/application.id/loudness/media.filter (don’t know about that but some shows the filter that got applied like cork) - of that command if -debug is attributed and paplay is the base command (don’t know about pure ALSA))
This is a sample output while playing emby (over a jellyfin server - yet this is basically identical codebase). Note that i’m using a combined sink where all streams get funneled through. (which is a filter btw)
Generally, it’s better to test with mpg123 (mp3) / paplay -pulseaudio- or aplay -ALSA- (wav), since this is the usual way the “simple” audioservice is playing things. There are skills (TuneIn) which force the vlc audioservice tho.
Just for testing purposes, you too are able to force vlc backend as default by adding Audio: { “default-backend”: “vlc”} to your system mycroft.conf (while testing use sudo tail -f -n30 /var/log/mycroft/audio.log to confirm)
the paplay command can play the audio file, but I cannot get mpg123 to play it at all. The aplay command plays noise, but its not the music I was expecting. Just a high pitch then what sounds like a broken radio. Changing the backend to VLC didn’t work at all (output of audio.log).
Here’s a thought: can mycroft play flac files? Maybe that’s what’s causing the issue?
How do I check VLC’s logs? I can only find people talking about enabling logging through the VLC GUI, which isn’t helpful for a headless device.
I’ll ask Fnor what they did because I think we had the same issue, but under different names. I’ll ask them what exactly they did because I don’t understand much in the way of Python or coding at all.
File logger (file)
--file-logging, --no-file-logging
Log to file
(default disabled)
Log all VLC messages to a text file.
--logfile=<string> Log filename
Specify the log filename.
--logmode={text,html} Log format
Specify the logging format.
--log-verbose={-1 (Default), 0 (Info), 1 (Error), 2 (Warning), 3 (Debug)}
Verbosity
Select the logging verbosity or default to use the same verbosity
given by --verbose.
@gez-mycroft we might want to run vlc with --logfile=
I ended up changing strategies and submitted a patch to the emby skill that used the new emby api to transcode everything to mp3. It has some weirdness, but you can force transcoding by lowering the bitrate in the media request URI to something below the bitrate of the original. This is done in the skill code itself.
At the end of the day I’m just using the default audio engine with this setup. Sorry I can’t be of more assistance with vlc.
The changes were committed a while ago, so if your emby skill is updated and you’re using default audio (not vlc) it should work. If you’re using default audio and it’s still not working, that means emby isn’t transcoding, which unfortunately is an emby issue that has not yet been addressed.
To force transcoding, change the media request URI to a lower bitrate than the media; the container flag doesn’t always trigger transcoding, but bitrate always does. This is line 130 of the emby_client.py file:
Change the MaxStreamingBitrate below your source bitrate, or if you don’t know that try successively lower bitrates until you get just below it. That will force emby to serve a transcoded mp3 file that picroft’s default sound engine can interpret.
Gotcha. Unfortunately, this did not help. I brought the MaxStreaming bitrate down from 140k kb, to 128 kb and then finally to 100 kb, and that didn’t help. Same output from audio.log and skills.log as before. I tried to bring the bitrate lower down to just 50 kb, but then I got another error. Maybe I just need to manually convert all the music files to MP3 until a more refined player works with Mycroft.
Just in case I did something wrong, here’s the lines I edited in the emby_client.py file.
Just a quick update: I converted some music files to .mp3 for testing, and now it works fine. I really would like to avoid having two copies of the same file stored because my storage space is fairly limited right now. In the Emby WebUI, I can see that some files are trying to be transcoded, but nothing happens. I am inclined to believe this is more of an Emby issue rather than a mycroft issue because of this. Also, I don’t know why the transcoding folder is labeled “Ride the Lightning”, or why it has all the metadata of said album.
