Picroft not playing music through Emby

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.

new audio.log output
new skills.log output

Any way to get get a more verbose output of Picroft to try and pin down the issue closer to the source?

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)

I got no output using the pactl command. I manually copied over a music file and installed vlc on the Pi and got audio playing that way.

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?

Check the log for details. Have you? the vlc ones. This might be interesting.

You’re saying “it”, what indicates that you want to play the same file with format specific programs. This won’t work.

There you go, flac:
Someone 2 months ago proposed a change to play flac. search flac in the forum search.

Not exactly a proposal, but you might wanna ask @Fnor what has happened since

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.

Thanks for you help!

I see file logging is disabled by default

(vlc)

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’m hesitant to add this into Mycroft itself, though I guess it could be done in the VLC audioservice when the log level is set to debug…

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.

I’m interested in that route. Could you guide me through how to accomplish what you did?

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:

url = '{0}{1}/{2}/{3}?userId={4}&API_KEY={5}&MaxStreamingBitrate=140000000&AudioCodec=mp3'\

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.

I can’t find the emby_client.py file. Where is it? Using “find” yields no results.

Skills are located at /opt/mycroft/skills on picroft installations.

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.

Another update: I firmly believe this issue rests on Emby and not mycroft after deciding to review the logs. I’ve created a topic over there, and they informed me that this a bug with Emby. I’ll close the issue here, as this is not a bug with mycroft.

1 Like

Final update: it appears Emby has been updated somewhat recently, and now everything works fine. I don’t see a way to close the issue, so if anyone has issues, please create a new thread.