RhythmiRust crashes before starting download phase for playlists

[Held-Brolly]

I've tried running the 2011 version of RhythmiRust on two devices and the same thing happens on both.

1. I can log in and synchronize with Spotify without issue.
2. My 'Liked' playlist downloads no problem.
3. When I try 'playlists', it gathers the info to 100% without problem.
4. As soon as it starts downloading files, the program quits.
5. Restarting shows no signs that the previous 'gathering' took place and it just starts all over again.

I've tried later versions of the program, but none of those open for me.
I've running the program on a 4 year old Win11 laptop, downloading to an external hard drive..

Any suggests on a possible fix would be appreciated.

[UnknownSuperficialNight]

Is there a log file in RhythmiRust_config/

if so post it here please.

[Held-Brolly]

Is there a log file in RhythmiRust_config/

if so post it here please.

I'm not entirely sure if this is the log, as I've tried running the program several times. But the text file has this;

Panic occurred at RhythmiRust/src/data/downloader/download_remote_host.rs:738.
Reason: called `Result::unwrap()` on an `Err` value: SqlInputError { error: Error { code: Unknown, extended_code: 1 }, msg: "unrecognized token: \"` LIMIT 1\"", sql: "SELECT codec FROM `Spotify\\•°'●COLDCORE●`°•` LIMIT 1", offset: 53 }
Date: 2026-06-14 19:49:39

Panic occurred at RhythmiRust/src/data/deps_download.rs:74.
Reason: Failed to download FFmpeg: Custom { kind: UnexpectedEof, error: "Peer disconnected" }
Date: 2026-06-14 13:29:59

[UnknownSuperficialNight]

Yep that is it try deleting the log and run the downloader again to produce a fresh log and upload it here if you can please

[Held-Brolly]

Yep that is it try deleting the log and run the downloader again to produce a fresh log and upload it here if you can please

Thanks. On it. I'll drop the log in here once the current gathering finishes and inevitable crash/involuntary closing happens again.

[Held-Brolly]

Here you go. Generated straight after the crash.

Panic occurred at RhythmiRust/src/data/downloader/download_remote_host.rs:738.
Reason: called `Result::unwrap()` on an `Err` value: SqlInputError { error: Error { code: Unknown, extended_code: 1 }, msg: "unrecognized token: \"` LIMIT 1\"", sql: "SELECT codec FROM `Spotify\\•°'●COLDCORE●`°•` LIMIT 1", offset: 53 }
Date: 2026-06-14 22:29:14

[UnknownSuperficialNight]

Ah, thank you, I think I know the problem (sanitization). I have fixed this already, I believe, but I'm still working on the next update. Here is a build I made awhile back that should fix the issue.

RhythmiRust.zip

Let me know if it works.

[Held-Brolly]

Ah, thank you, I think I know the problem (sanitization). I have fixed this already, I believe, but I'm still working on the next update. Here is a build I made awhile back that should fix the issue.

RhythmiRust.zip

Let me know if it works.

Thanks. Downloaded and will run shortly. Will keep you updated no matter what happns!

[Held-Brolly]

OK, well. Firstly, can I say how much I appreciate your efforts in creating and maintaining such a program. It's really very nifty!

Now with regards to the latest update. Good news is the playlist download begun, for the first time ever, and managed to get through almost 25%. Then crashed. But that's progress! :)

Not sure if there's any more that can be done, but here is the latest log;

Panic occurred at ./.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-wgpu-0.33.3/src/renderer.rs:958.
Reason: Failed to create staging buffer for index data. Index count: 6084. Required index buffer size: 24336. Actual size 112320 and capacity: 112320 (bytes)
Date: 2026-06-15 21:48:09

Edit: Just started the program again. It's a shame that everything has to start again from zero after a crash. It takes about an hour to gather the info, then was running for about 2 hours to get to 25% before crashing. If there was a way to have the program start where it ended, that would save so much time, especially in testing. But I guess that's not a possibility.

[UnknownSuperficialNight]

OK, well. Firstly, can I say how much I appreciate your efforts in creating and maintaining such a program. It's really very nifty!

Aww, thank you ❤️

Now with regards to the latest update. Good news is the playlist download begun, for the first time ever, and managed to get through almost 25%. Then crashed. But that's progress! :)

Not sure if there's any more that can be done, but here is the latest log;

Panic occurred at ./.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-wgpu-0.33.3/src/renderer.rs:958.
Reason: Failed to create staging buffer for index data. Index count: 6084. Required index buffer size: 24336. Actual size 112320 and capacity: 112320 (bytes)
Date: 2026-06-15 21:48:09

Well, the good news is that the issue has nothing to do with the downloader. Instead, it was the GUI that crashed. The downloader was working perfectly.

Bad news it's out of my hands. There seems to be a regression that could possibly be causing this upstream, or it could be hardware specific, but it seems some other people are getting it and its sporadic.

I'm looking into this.

Here is a link to a discussion about it:

Link

In the meantime, try again, and maybe only download liked, then playlists separately.

The good news is with each run, the next run should get faster slightly as successful downloads are cached.

Edit: Just started the program again. It's a shame that everything has to start again from zero after a crash. It takes about an hour to gather the info, then was running for about 2 hours to get to 25% before crashing. If there was a way to have the program start where it ended, that would save so much time, especially in testing. But I guess that's not a possibility.

I'm afraid not, since it has to cross-search each time for songs, so caching the songs in that state would not really be useful as what if, when we run it again, we get a different version of the song example official vs lyrics etc, then we will have two of the same song. Also, sometimes some songs just won't download, be it your network or theirs or etc, things can happen. I typically would run it, let it finish, and then, like a week or a few days later, run it again one last time to pick up stragglers.

[Held-Brolly]

Here's the log from the most recent crash, for your reference, just in case;

Panic occurred at ./.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-wgpu-0.33.3/src/renderer.rs:958.
Reason: Failed to create staging buffer for index data. Index count: 6138. Required index buffer size: 24552. Actual size 112224 and capacity: 112224 (bytes)
Date: 2026-06-15 22:40:30

Bad news it's out of my hands. There seems to be a regression that could possibly be causing this upstream, or it could be hardware specific, but it seems some other people are getting it and its sporadic.

Bad news it's out of my hands. There seems to be a regression that could possibly be causing this upstream, or it could be hardware specific, but it seems some other people are getting it and its sporadic.

Ahh, here comes my ignorance! Does that mean it can't be solved?

In the meantime, try again, and maybe only download liked, then playlists separately.

Yeah, Liked downloaded first time, without issue. Just the Playlists that fail. Is there any way to choose which Playlists download, or is it all or nothing? Sorry, I'm sure it's in the Wiki, I'm just being lazy at 1am here. 😉

The good news is with each run, the next run should get faster slightly as successful downloads are cached.

Interesting. So are you saying it won't actually need to start from zero? I'm a literally confused between this reply and what you mentioned at the last point.

In either case, thanks very much for taking the time to reply!

[UnknownSuperficialNight]

Here's the log from the most recent crash, for your reference, just in case;

Panic occurred at ./.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-wgpu-0.33.3/src/renderer.rs:958.
Reason: Failed to create staging buffer for index data. Index count: 6138. Required index buffer size: 24552. Actual size 112224 and capacity: 112224 (bytes)
Date: 2026-06-15 22:40:30

Yep same issue GUI rendering

Bad news it's out of my hands. There seems to be a regression that could possibly be causing this upstream, or it could be hardware specific, but it seems some other people are getting it and its sporadic.

Bad news it's out of my hands. There seems to be a regression that could possibly be causing this upstream, or it could be hardware specific, but it seems some other people are getting it and its sporadic.

Ahh, here comes my ignorance! Does that mean it can't be solved?

No, it's an upstream issue. I depend on a graphics handling project, and there's a known regression there causing sporadic crashes for some users. It appeared fixed but is happening again. I'm willing to help the upstream maintainers investigate and fix this (It's a process of discovery and normally requires quite a few people to help diagnose the issue so it won't just be me but other devs from other projects). Once the upstream issue is addressed, the fix will need to be pulled into my project.

In the meantime, try again, and maybe only download liked, then playlists separately.

Yeah, Liked downloaded first time, without issue. Just the Playlists that fail. Is there any way to choose which Playlists download, or is it all or nothing?

Nope, unfortunately, it's due to how it's implemented. The thing that is taking long is the search. That's why it takes awhile, as it has the song names, then it searches for the songs themselves to download.

Sorry, I'm sure it's in the Wiki, I'm just being lazy at 1am here. 😉

XD don't worry its 4am here.

The good news is with each run, the next run should get faster slightly as successful downloads are cached.

Interesting. So are you saying it won't actually need to start from zero? I'm a literally confused between this reply and what you mentioned at the last point.

The search will start from zero, since between searches we can get slightly different results. However, for songs already downloaded they will not be downloaded again thus they are skipped.

Please note this is only for Spotify. The other downloading system in Playlist Editor caches everything and is way faster than Spotify. It's just that Spotify has more steps I need to do to get the songs, find where I can download them and then download them.

Hopefully that clears things up?

In either case, thanks very much for taking the time to reply!

No problem at all :)