Latest version 1.0.1 fails to write the audio file.

[0rkaM]

It seems that everything works well, except for writing the actual audio file: it download get the metadata, but when it comes to finalize the file and write it there is an error and OtS fails
Log error says:

[2024-11-07 22:12:51,521 :: downloader :: downloader.py -> 347:                 run() :: ERROR] -> Unknown Exception: [WinError 206] The filename or extension is too long

Every file in the playlist either fails, or already exists, so in the latter the path or name are not too long, since it sees it, it fails only when it has to write the file.
Does it copy from a temp location?

I did not change the folder tagging neither the destination folder.

Instead, the previous version... I am calling it 1.0.0rcB, after rcA, rc9, rc8, etc... works correctly with the same playlist.

Did you change any of the libraries.

[justin025]

I hate windows.

It seems like every release I put out your machine has a problem with I'm really sorry about that, please send me your config file (minus your account) the exact os version (ex: Windows 10 22H2) and I will try correcting all your past issues in a vm. For now you can try resetting your settings but I did not make any notable changes to the file tagging.

[Honkertonken]

+1 facing the same issue.

Also unrelated issue but the album cover image is saved even though it is set to false, while the audio file itself is not saved.

[justin025]

2024-11-08_10-24-35.mp4

I assume you guys can understand my frustration, please provide logs, your config file, and your os version if possible. The following is from windows 11 23H2

[Honkertonken]

OS : Windows 10 21H2
Config : otsconfig.json
Logs : onthespot.log
Removed a few things in logs just to be safe.

[justin025]

Someone on discord helped me determine that this issue only happens when the app tries to embed a thumbnail to an ogg file on windows. If you disable embed cover or switch to mp3 does the issue persist?

…

On Friday, November 8th, 2024 at 5:08 PM, Honkertonken ***@***.***> wrote: OS : Windows 10 21H2 Config : [otsconfig.json](https://github.com/user-attachments/files/17681773/otsconfig.json) Logs : [onthespot.log](https://github.com/user-attachments/files/17681868/onthespot.log) Removed a few things in logs just to be safe. — Reply to this email directly, [view it on GitHub](#50 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BESVWLJHRQQURB5CWIMAICTZ7TVYLAVCNFSM6AAAAABRMYZUDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGMYDAMRXGA). You are receiving this because you commented.Message ID: ***@***.***>

[Honkertonken]

Works fine when switching to mp3.

[stevecole90099]

The error about the filename being too long could be exactly that. Depending on where you are downloading the files to, the path may be too long. I had an issue with this and had to move my folder from the default to C:\music to solve it.

[0rkaM]

All the Previous Version up to 1.0.0rc9 and the two artifact that you linked in my previous reports (I call them rcA and rcB) worked fine on Ogg files.

Here is the edited config file:
otsconfig - Copy (2).json

[solunafantasy]

This is an issue for me. I shouldn't have deleted RC9 off my machine. Does anyone have a copy of RC9 since its removed from here?

[justin025]

Should be fixed with this commit, sorry about that https://github.com/justin025/onthespot/actions/runs/11757275003

[justin025]

@solunafantasy The github actions tab produces an exe for every commit, i would say https://github.com/justin025/onthespot/actions/runs/11634094594 is about rc-9

[solunafantasy]

Immediately fails to execute 1.0.2. version 92
version 90 Executes fine. Testing. Ok. Ogg downloads working cover art bug seems to be fixed.

[justin025]

someone else pointed that out just fixed it

[0rkaM]

This is an issue for me. I shouldn't have deleted RC9 off my machine. Does anyone have a copy of RC9 since its removed from here?

That is what I noticed to, there were no incrementals since v0.7.1, it was hard for me to see the variation of the code and there was no way to help, nor see what worked and what not.
Anyway, I have only the Windows' compiled not the source code, if you still need them, I have RC4, RC5, RC6, RC7, RC9, RC9.a, RC9.b (RC9 is the good one for me), let me know where to upload them, since I think here the attachment limit is 25MB.

The error about the filename being too long could be exactly that. Depending on where you are downloading the files to, the path may be too long. I had an issue with this and had to move my folder from the default to C:\music to solve it.

That is not the case for me, since my music paths are the MS Windows standard %HOMEPATH%\Music and the other that I also tried with the same result is D:\Music.

[justin025]

I did not do incrementals because 0.7.1 and 1.0 are two different apps I've rewritten most of the app. Soluna managed to download my prerelease just as I was testing it hence the error. The fix to this issue and a few others is published here https://github.com/justin025/onthespot/releases/tag/v1.0.2

I believe after this release the app will be stable and far more hands off than it has been thus far, I really apologize for all the bugs you guys have experienced

[0rkaM]

Don't worry, this is what development is. v1.0.2 seems to not be affected by this bug and it seem to work way faster.
There were few other audio files that reacted in a weird way though, not sure where the problem is and since it does not say what file was processing, I don't know if it downloaded successfully, and neither if all the tags are there, but the log sometime shows stuff like this this:

[2024-11-09 19:39:25,778 :: downloader :: downloader.py -> 350:                 run() :: ERROR] -> Unknown Exception: 'charmap' codec can't encode character '\u010c' in position 33: character maps to <undefined>

But other than that it seems to work.

[justin025]

The charmap issue seems to be an extension of the following link without the loop #42

[0rkaM]

If so to solve it, probably it has the same necessity and since they seem not to be critical, I suggest handling it the same way: leave it alone for a later date 'will fix', when more info about it is gathered, which will give a clearer hint on how to handle it...