Track recorded on the same file as the precedent track

[eros404]

Hi !

First really nice project.
My first recording sessions worked well.

But today I try to do another and as you can see Spytify record the first track well.
Then for the second track it will overwrite the audio of the first one.

Version: 1.10.1

In final for 2 tracks recorded I end with 1 file with the ID3 data of the first and the audio of the second.

Edit:
So I have downloaded again Spytify and the bug is not happening for now.

Edit 2:
It happened again :/

[Coca162]

This seems to be happening when I move or add anything to a playlist above the current song (i.e. a song before the current playing song)

[eros404]

It happens for me but i didn't move anything, just launched my playlist and wait.

[rikrak]

@Coca162 I've just tried to record a playlist without changing anything, but this issue still occurred. In my scenario the logs looked like this (spacing mine for clarity):

[08:36:34] Recording: Song 01

[08:39:29] Recording: Song 02
[08:39:32] Recorded: ..\Song 01.mp3 in 02:55

[08:43:41] Recording: Song 03
[08:43:46] Recorded: ..\Song 02.mp3 in 04:11

[08:46:46] Recording: Song 04
[08:46:49] Recorded: ..\Song 02.mp3 in 03:03        <--- Song 03 recorded with Song 02's details

[08:50:43] Recording: Song 05
[08:50:47] Recorded: ..\Song 04.mp3 in 03:56

[08:55:22] Recording: Song 06
[08:55:27] Recorded: ..\Song 05.mp3 in 04:38

[08:59:28] Recording: Song 07
[08:59:33] Recorded: ..\Song 06.mp3 in 04:05

[09:04:11] Recording: Song 08
[09:04:16] Recorded: ..\Song 06.mp3 in 04:41      <--- Song 07 recorded with Song 06's details

[09:08:39] Recording: Song 09
[09:08:44] Recorded: ..\Song 07.mp3 in 04:27      <--- Song 08 recorded with Song 07's details

[09:12:52] Recording: Song 10
[09:12:57] Recorded: ..\Song 09.mp3 in 04:11

[09:15:38] Recording: Song 11
[09:15:40] Recorded: ..\Song 09.mp3 in 02:45      <--- Song 10 recorded with Song 09's details

[rikrak]

I've had a look into the code and I've narrowed down the cause of this.
The Track class has a method that allows the Title to be set once information has been taken from an API. Additionally the Title property on Track will return the _apiTitle in preference to the original title it had. This essentially means the Title property can change its value at some point in its lifespan.

What appears to be happening is that when a new track is queued up, the previous track is written to disk. This all happens at the same in an asynchronous manner. A process goes off to discover the title for the new track from an API, but when it is set, it uses the title from the previous track.

The track's Title property is used to form the file names, so this is where the problem begins.

I haven't spotted a solution, but at least I'm closer to the cause :-)

[jwallet]

Are you guys using Spotify desktop app from spotify website (.exe file downloaded) or from the Windows Store? I did not have an issue like that and I'm using the app from Windows Store.

[rikrak]

Ah! I'm using a version built from the github code. I wanted to edit the code to prefix file names with a track number

[Coca162]

After using Spytify for a bit more I do indeed have this issue even when not moving anything around.

Also @jwallet I am using the Spotify desktop app from the exe.

[eddwhite]

I have also started encountering the same problem. I've been using release 1.10.1 for a while, and this only started happening recently. I've also noticed that this doesn't happen when using the LastFM API instead of the Spotify API

[rikrak]

It could well be something that has changed at Spotify's side. If the API takes a little longer to respond than previously it could have exposed a race condition in the existing code.

[jwallet]

Anyone tried to record using Spotify from the Windows Store, I'm currently recording and I still have no problem, 23 tracks recorded so far, none missing. So I'm wondering if I using the .exe file from their website produces that bug. Of course while recording it's better to keep the windows session active and not lock your PC for example, Spytify will still record, but if I remember correctly Spotify won't provide track info if the window is not rendered at all (like the screen went to sleep). I'm thinking to add a caffeine feature to the app if that is the issue.

If someone will like to help out, you can try one of the following "solution" to know if one of these fixes the bug;

• Record using Spotify from the Windows Store --- probably not the solution if LastFM API works
• Keep Spotify window foreground while recording (not minimized in the tray)
• Use caffeine app to prevent the computer to go to sleep (it simulates a keypress every minute)

[jwallet]

did someone here tried the latest release? I would like to know if it resolved the issue

[rikrak]

For info: I've update my fork of the code, re-built, and run a test today. I'm not seeing the problem anymore :-)

• recorded a playlist of > 18 tracks
• I was using Spotify API for naming/tagging
• Spotify was in the background, but not minimised
• Spytify was in the background, but not minimised
• I was using other apps (Visual Studio) for the duration of the recording

[eddwhite]

I've updated to the latest release (love the auto-update feature btw!) and I am no longer encountering this problem 🥳

[jwallet]

i'm closing this issue then, thanks all for your feeback it's appreciated