mirror of
https://github.com/jpochyla/psst.git
synced 2026-04-27 15:35:56 +03:00
[GH-ISSUE #301] Playing songs not in the cache broken #219
Labels
No labels
api
bug
build
documentation
duplicate
enhancement
good first issue
help wanted
idea
invalid
linux
lowprio
macos
pull-request
upstream
windows
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/psst#219
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @omartijn on GitHub (May 20, 2022).
Original GitHub issue: https://github.com/jpochyla/psst/issues/301
Describe the bug
Playing any song that isn't already in the cache no longer works
To Reproduce
Play a song that isn't already cached.
Expected behavior
The sons plays
Screenshots
Environment
Additional context
It looks strongly related to authentication. Of particular interest is the
psst_core::session::access_token] access token expired, requestingmessage, which pops by regularly. I've tried going back two commits (to before the change masquerading as librespot) and that version tells me I need a premium account (which I have). The latest master tells me "success" when logging in, but then doesn't play.@luukvanderduim commented on GitHub (May 20, 2022):
I encounter the same problem. Songs I have in cache play, new songs elicit:
Ubuntu 22.04
FWIW, here is the backtrace:
@omartijn commented on GitHub (May 23, 2022):
I just noticed something strange while debugging. This error occurs when I run the release-build of
psst-gui, but not when I run the debug build.What i normally do is
cargo install --path psst-gui --profile releaseafter pulling the latest changes, I then have apsst.desktopfile so that I can easily start it (or start it from the terminal, as I have added the rust bin folder to my PATH).When instead I do
cargo run --bin psst-gui, it actually works as expected. Strangely enough, though it uses the same config file, it showed me as logged out when I started it the first time. After logging in it worked. So there is something different in the way it loads credentials.To show, first output is from
cargo run --bin psst-gui(I've omitted the compilation steps here), second ispsst-guifrom myPATH(which is the release build.@omartijn commented on GitHub (May 23, 2022):
It doesn't seem to have anything to do with release/debug specifically. Running
cargo run --bin psst-gui --profile releaseruns the optimized build, which then also seems to work just fine. It's just the installed version that seems to be broken.@luukvanderduim How are you running
psst-gui? Do you get the same behaviour?@omartijn commented on GitHub (May 23, 2022):
OK, I think I'm onto something. It seems something goes wrong when you do multiple builds without cleaning the repo in-between. That's why doing the
cargo runcommands initially worked. Strangely enough, doing that command again and running another build broke it again like before.What worked for me is to do
git clean -ffxdand then doing acargo run --bin psst-gui --profile release. This gave me a functioning executable again. I then manually copied this executable to my~/.cargo/binfolder - since doing anothercargo install ...would do another build which would be broken.@luukvanderduim commented on GitHub (May 23, 2022):
@omartijn
Sharp observations!
I do
cargo install --path=.inpsst/psst-guiand then just run bypsst-gui.cargo cleanandcargo install --path=.leads to a broken broken install.git clean -ffxdandcargo install --path=.also led to a broken install.cargo cleanandcargo rr --bin=psst-guileads to a working instance.The working builds have the
rustlswarnings whereas the broken builds do not.@luukvanderduim commented on GitHub (May 23, 2022):
When stracing (
strace --status=failure target/release/psst-gui) both binaries, the first differing syscall (in the failing binary) is:prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)So it fails to read its 'thread capability bound set'.
@luukvanderduim commented on GitHub (May 23, 2022):
cargo install --path=psst-gui --lockedresults in a working build for me.It seems
cargp build(or run) do honor Cargo.lock whereascargo installignores it.@omartijn Does this fix your build too?
@luukvanderduim commented on GitHub (May 25, 2022):
It appears that sometimes
startis greater thanendand this makes theu64::subpanic in psst-core/src/player/storage.rsThis is the 'fix' to avoid the panic. This works fine(tm) up-until-now.
But note that I have no clue how
startends up being greater thanendand how this problem is introduced by newer dependencies as we have seen earlier in the thread.@omartijn commented on GitHub (May 26, 2022):
@luukvanderduim
--lockedoption produces a working build for me as well. I think we can conclude this has something to do with cargo pulling in updated dependencies without this flag.@jpochyla commented on GitHub (May 30, 2022):
Fuuu, what a strange bug! Thanks for the extensive detective work, but so far I have no idea what's going on.
@luukvanderduim commented on GitHub (Jun 5, 2022):
I think I narrowed it down to the
rangemapversionbump from v1.0.1 to v1.0.2. To be specific, commit 9d0b12572278ee94e78ecabfccc43e6edd3b96ba seems to first introduces the bug.cargo update&&cargo upgrade --workspace// update all dependencies in the workspacecargo clean&&cargo run --bin psst-gui --locked// to confirm updated dependencies introduces the problemcargo clean&&cargo run --bin psst-gui --locked// to confirm updatedrangemapcrate introduces the bugpsst-core/Cargo.tomltherangemapdependency to point ot a local cloned repositoryrangemap = { path = "../../rangemap/" }@luukvanderduim commented on GitHub (Jun 10, 2022):
In order to see what behavior changed in jeffparsons/rangemap I copied (~30) tests from rangemap::map to rangemap::set as we are most interested in
RangeSet.Then I copied all
settests to the v1.0.1 commit too and found one test that fails in v1.0.1, but passes in v1.0.2:Which fails like so:
Considering the definition of what is contained in a range, this may be a bug, and may have introduced our bug here (but may even be unrelated still).
Filed an issue for this: jeffparsons/rangemap#47
@jeffparsons commented on GitHub (Jun 11, 2022):
I've just released version 1.0.3 of rangemap with this issue fixed.
@luukvanderduim commented on GitHub (Jun 12, 2022):
@jeffparsons fixed this bug with jeffparsons/rangemap v1.0.3.
I found a case that has v1.0.2
rangeset..gaps()return a range where start > end where it should returnNone(see: jeffparsons/rangemap#47 )Found it like this:
In
psst-core/src/playter/storage.rs(note that I am not suggesting to use this code in psst, just for obtaining a test case)
I think this bug can be closed when we set the dependency >1.0.2 in
psst-core/Cargo.toml?@jpochyla commented on GitHub (Jun 13, 2022):
Big thanks, everybody! ❤️ I've merged #304, can you confirm it fixes the bug?
@omartijn commented on GitHub (Jun 13, 2022):
Seems to work fine here. I've built the latest master, removed
~/.cache/Psstand startedpsst-gui. It plays tracks fine.One little thing I noticed is that the first time I started it it wouldn't play tracks. Then I started it fresh and it worked. No idea what was going on there.