Playing songs not in the cache broken #301
Comments
|
I encounter the same problem. Songs I have in cache play, new songs elicit: Ubuntu 22.04 |
|
I just noticed something strange while debugging. This error occurs when I run the release-build of What i normally do is When instead I do To show, first output is from |
|
It doesn't seem to have anything to do with release/debug specifically. Running @luukvanderduim How are you running |
|
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 What worked for me is to do |
|
@omartijn
The working builds have the |
|
When stracing ( So it fails to read its 'thread capability bound set'. |
|
@omartijn Does this fix your build too? |
|
It appears that sometimes This is the 'fix' to avoid the panic. This works fine(tm) up-until-now. fn range_to_offset_and_length(range: &Range<u64>) -> (u64, u64) {
- (range.start, range.end - range.start)
+ (range.start, range.end.saturating_sub(range.start))
}But note that I have no clue how |
|
@luukvanderduim |
|
Fuuu, what a strange bug! Thanks for the extensive detective work, but so far I have no idea what's going on. |
|
I think I narrowed it down to the
|
|
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 #[test]
fn empty_outer_range_with_items_away_from_both_sides() {
let mut range_set: RangeSet<u32> = RangeSet::new();
// 0 1 2 3 4 5 6 7 8 9
// ◌ ◆---◇ ◌ ◌ ◌ ◌ ◌ ◌
range_set.insert(1..3);
// 0 1 2 3 4 5 6 7 8 9
// ◌ ◌ ◌ ◌ ◌ ◆---◇ ◌ ◌
range_set.insert(5..7);
// 0 1 2 3 4 5 6 7 8 9
// ◌ ◌ ◌ ◌ ◆ ◌ ◌ ◌ ◌ ◌
let outer_range = 4..4;
let mut gaps = range_set.gaps(&outer_range);
// Should yield a gap covering the zero-width outer range.
assert_eq!(gaps.next(), Some(4..4));
// Gaps iterator should be fused.
assert_eq!(gaps.next(), None);
assert_eq!(gaps.next(), None);
}Which fails like so: ---- set::tests::empty_outer_range_with_items_away_from_both_sides stdout ----
thread 'set::tests::empty_outer_range_with_items_away_from_both_sides' panicked at 'assertion failed: `(left == right)`
left: `None`,
right: `Some(4..4)`', src/set.rs:789:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtraceConsidering 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). |
|
I've just released version 1.0.3 of rangemap with this issue fixed. |
This contains a fix that will hopefully solve jpochyla#301.
|
@jeffparsons fixed this bug with jeffparsons/rangemap v1.0.3. I found a case that has v1.0.2 Found it like this: fn not_yet_requested(&self, offset: u64, length: u64) -> Vec<(u64, u64)> {
#[cfg(debug_assertions)]
let backup = self.requested.lock().clone();
self.requested
.lock()
.gaps(&(offset..offset + length))
.into_iter()
.map(|r| {
if r.start > r.end {
println!("Outer range: offset ({0}) .. offset ({0}) + length ({1})", &offset, &length);
println!("Method gaps returns start>end ranges is called on RangeSet: {:?}", backup);
std::process::exit(1);
}
range_to_offset_and_length(&r)
})
//.map(|r| range_to_offset_and_length(&r))
.collect()
}(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 |
This contains a fix that will hopefully solve #301.
|
Big thanks, everybody! ❤️ I've merged #304, can you confirm it fixes the bug? |
|
Seems to work fine here. I've built the latest master, removed 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. |
This contains a fix that will hopefully solve jpochyla/psst#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.The text was updated successfully, but these errors were encountered: