Ability to play a specific track while using Spric?

[oeed]

For context, I'm making my own player app and I'd like a way to play specific tracks on demand by calling librespot (rather than a headless speaker).

The Player has methods like load to allow you to do so, but when wrapping the player with Spric to allow connections it doesn't seem possible as it takes ownership of it, makes it private and doesn't expose methods to do so. Is there a way to achieve what I'm after locally (i.e. without encountering the latency/lack of ability to use offline from using a web API)?

[roderickvd]

Not really. Player originally started as an expanded example, and now has grown into the full-fledged Connect player that it is. If you find ways of making it more flexible, a PR would be welcome.

[oeed]

Thanks for you quick reply, I've been working on a PR to add a load() command to Spric which is working (I think that's the best approach as lots of the 'load next track' etc logic is in there rather than the player).

However, I've found that when librespot isn't active (i.e. the naive Spotify app is playing) commands (even existing ones) don't seem to do anything. Here's a minimum repo, basically if I switch output to librespot it'll play/pause every 5 seconds, but if I go through the Spotify app it won't. Is this just a limitation, or am I doing something wrong?

use std::env;

use librespot::core::authentication::Credentials;
use librespot::core::config::SessionConfig;
use librespot::core::session::Session;
use librespot::playback::audio_backend;
use librespot::playback::config::{AudioFormat, PlayerConfig};
use librespot::playback::mixer::NoOpVolume;
use librespot::playback::player::Player;
use librespot_connect::spirc::Spirc;
use librespot_core::config::ConnectConfig;
use librespot_playback::mixer::softmixer::SoftMixer;
use librespot_playback::mixer::{Mixer, MixerConfig};

#[tokio::main]
async fn main() {
    let session_config = SessionConfig::default();
    let player_config = PlayerConfig::default();
    let audio_format = AudioFormat::default();
    let connect_config = ConnectConfig::default();

    let args: Vec<_> = env::args().collect();
    if args.len() != 3 {
        eprintln!("Usage: {} USERNAME PASSWORD", args[0]);
        return;
    }
    let credentials = Credentials::with_password(&args[1], &args[2]);

    let backend = audio_backend::find(None).unwrap();

    println!("Connecting ..");
    let (session, _) = Session::connect(session_config, credentials, None, false)
        .await
        .unwrap();

    let (player, _) = Player::new(
        player_config,
        session.clone(),
        Box::new(NoOpVolume),
        move || backend(None, audio_format),
    );

    let (spirc, spirc_task) = Spirc::new(
        connect_config,
        session,
        player,
        Box::new(SoftMixer::open(MixerConfig::default())),
    );

    let mut spirc_task = Box::pin(spirc_task);
    loop {
        tokio::select! {
          _ = async { (&mut spirc_task).await } => {},
          _ = async { tokio::time::sleep(tokio::time::Duration::from_secs(5)).await } => {
            println!("Play/pause");
            spirc.play_pause();
          }
        }
    }
}

Thanks

[kingosticks]

The player/core needs extending to support generic controller functionality. Currently there's some logic somewhere which ignores spirc commands when librespot isn't the active player and/or don't target librespot. If you haven't already, you need to fix that and then untangle anything that assumes it.

[oeed]

I do see that there's the CommandSender struct, that seems like it should be sending the commands, but don't specifically see anywhere where it's short circuiting.

For my uses at this stage it's probably fine as is though, I'll tidy up my changes and PR them shortly.

[roderickvd]

I am not sure what the intention behind your minimally-reproducible code is, but I do not think you should await in the the select! arms like that. The select! documentation mentions how you should work with timers there.

[oeed]

I do see that there's the CommandSender struct, that seems like it should be sending the commands, but don't specifically see anywhere where it's short circuiting.

For my uses at this stage it's probably fine as is though, I'll tidy up my changes and PR them shortly.

Turns out I've been looking at the master branch, not dev which is quite different, so disregard sorry!