starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 16:25:52 +03:00

[GH-ISSUE #178] Porting `tokio-core` to `tokio` #121

New issue

Closed

opened 2026-02-27 19:28:57 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 19:28:57 +03:00

Owner

Originally created by @dbischof90 on GitHub (Mar 2, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/178

Originally assigned to: @dbischof90 on GitHub.

As tokio-core is depreceated and both the futures and the tokio crate are getting overhauled for version 0.2, there will be a necessity in the medium term to port the code to tokio.

This is not pressing but will be more important at one point.

Originally created by @dbischof90 on GitHub (Mar 2, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/178 Originally assigned to: @dbischof90 on GitHub. As `tokio-core` is depreceated and both the `futures` and the `tokio` crate are getting overhauled for version 0.2, there will be a necessity in the medium term to port the code to `tokio`. This is not pressing but will be more important at one point.

kerem

2026-02-27 19:28:57 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 19:28:58 +03:00

Author

Owner

@brain0 commented on GitHub (Mar 20, 2018):

It seems that the tokio API is not quite stable yet. It's probably best to wait until futures 0.2 is stable and a tokio version compatible to futures 0.2 is stable as well. Some things have changed drastically and this is likely a bigger task.

@brain0 commented on GitHub (Mar 20, 2018): It seems that the tokio API is not quite stable yet. It's probably best to wait until futures 0.2 is stable and a tokio version compatible to futures 0.2 is stable as well. Some things have changed drastically and this is likely a bigger task.

kerem commented

2026-02-27 19:28:58 +03:00

Author

Owner

@ashthespy commented on GitHub (Jun 9, 2020):

@marcelbuesing @leshow
Moved here for the discussion. I've opened up a new project to track this, while we figure out the best way to tackle this?

My .2 cents - Core is turning out to be quite a nightmare, if we get core/mercury up and running, then it should be easier to start isolating the rest and writing simple test wrappers for them..
What do you all think?

@ashthespy commented on GitHub (Jun 9, 2020): @marcelbuesing @leshow Moved here for the discussion. I've opened up a new [project](https://github.com/librespot-org/librespot/projects/2) to track this, while we figure out the best way to tackle this? My .2 cents - Core is turning out to be quite a nightmare, if we get core/mercury up and running, then it should be easier to start isolating the rest and writing simple test wrappers for them.. What do you all think?

kerem commented

2026-02-27 19:28:58 +03:00

Author

Owner

@brain0 commented on GitHub (Jun 9, 2020):

The problem I see is that nobody really has the full overview of the librespot project (I personally have only touched a few areas). I would even prefer writing it (the library) in an executor-agnostic way, if that is even possible.

In any case, librespot should use std's futures and much of it could probably be rewritten using async.

@brain0 commented on GitHub (Jun 9, 2020): The problem I see is that nobody really has the full overview of the librespot project (I personally have only touched a few areas). I would even prefer writing it (the library) in an executor-agnostic way, if that is even possible. In any case, librespot should use std's futures and much of it could probably be rewritten using async.

kerem commented

2026-02-27 19:28:58 +03:00

Author

Owner

@ashthespy commented on GitHub (Jun 9, 2020):

The problem I see is that nobody really has the full overview of the librespot project (I personally have only touched a few areas). I would even prefer writing it (the library) in an executor-agnostic way, if that is even possible.

Pretty much in the same boat, but figuring out more as I refactor :-) We're quite deeply intertwined already with Tokio (as we use hyper and libmdns) so rewriting for use with async-std or smol is going to be hard (at this stage)

@ashthespy commented on GitHub (Jun 9, 2020): >The problem I see is that nobody really has the full overview of the librespot project (I personally have only touched a few areas). I would even prefer writing it (the library) in an executor-agnostic way, if that is even possible. Pretty much in the same boat, but figuring out more as I refactor :-) We're quite deeply intertwined already with Tokio (as we use `hyper` and `libmdns`) so rewriting for use with `async-std` or `smol` is going to be hard (at this stage)

kerem commented

2026-02-27 19:28:58 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Feb 23, 2021):

No longer relevant - PR in progess. #606

@sashahilton00 commented on GitHub (Feb 23, 2021): No longer relevant - PR in progess. #606

kerem commented

2026-02-27 19:28:58 +03:00

Author

Owner

@Siilwyn commented on GitHub (Feb 17, 2022):

For anybody trying this out I've found using smol & async_compat to work with librespot. :)

use async_compat::Compat;
use librespot_core::authentication;
use librespot_core::config;
use librespot_core::session;

fn main() {
    let credentials = authentication::Credentials::with_password(
        env::var("SPOTIFY_USERNAME").expect("Environment variable SPOTIFY_USERNAME not set"),
        env::var("SPOTIFY_PASSWORD").expect("Environment variable SPOTIFY_PASSWORD not set"),
    );

    smol::block_on(Compat::new(async {
        let user_session =
            session::Session::connect(config::SessionConfig::default(), credentials, None)
                .await
                .unwrap();
        println!("Connected as {}", user_session.username());
    }));
}

@Siilwyn commented on GitHub (Feb 17, 2022): For anybody trying this out I've found using `smol` & `async_compat` to work with librespot. :) ```rust use async_compat::Compat; use librespot_core::authentication; use librespot_core::config; use librespot_core::session; fn main() { let credentials = authentication::Credentials::with_password( env::var("SPOTIFY_USERNAME").expect("Environment variable SPOTIFY_USERNAME not set"), env::var("SPOTIFY_PASSWORD").expect("Environment variable SPOTIFY_PASSWORD not set"), ); smol::block_on(Compat::new(async { let user_session = session::Session::connect(config::SessionConfig::default(), credentials, None) .await .unwrap(); println!("Connected as {}", user_session.username()); })); } ```

kerem referenced this issue

2026-02-27 19:59:58 +03:00

[PR #121] [MERGED] Add track duration to Track metadata #791

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#121

No description provided.

Rows
Columns

[GH-ISSUE #178] Porting tokio-core to tokio #121

[GH-ISSUE #178] Porting `tokio-core` to `tokio` #121