Any fails from playllist also fail to write playlist down onto directory.

[0rkaM]

Bug Description

While the option to create a M3U file from playlist is checked, it will fail to do so. if any error with any file would occur even if only once and/or on a last file.

To fix this maybe we could have the app to write the full playlist even in event of an error; or maybe to first write down the M3U file before starting the download process, so if an error happens it does not really impairs also having the playlist file.

I have quite a few M3U playlist not written in the specified directory, because of a last-minute error, even if that error was not relevant and neither true: in fact, few time the error was about retrieving the metadata ('Get metadata failed'), while actually the audio file had all the metadata showing up just fine.

For example: Maski & Banga "Dangerous" downloaded fine and it is showing all the metadata including cover pic (also downloaded separately), maybe the Lyrics where not downloaded since I don't see the .lrc file, anyway all the songs of the playlist including this song downloaded completely, but 'Downloads' tab is showing the above mentioned error for this last one, so I guess it is not fully complete(?), and for that the playlist M3U file does not show in the directory.

Environment Details

| **Detail**               | **Your Information**   |
|--------------------------|------------------------|
| **Operating System**     | Windows 10             |
| **Application Version**  | v0.7.0                 |
| **Installation Method**  | GitHub Release v0.7.1  |
| **Python Version**       | 3.10.8                 |
| **FFmpeg Version**       | various versions local to program: 
                             Audacity, Losslesscut, 
                             TAudio Converter, FL Studio,
                             Roland Cloud,            |

Additional Information

No response

[justin025]

So let me clarify, you'd like the m3u file created immediately after download is successful regardless if metadata, thumbnail, lyrics etc fail.

If this is the case it should be easy enough to do

[0rkaM]

I would like that the m3u is created regardless of how many audio files, or their metadata, thumbnails, lyrics, etc. fails... so at least something it is saved and there is a complete playlist, with what I can work adding those missing audio files or metadata in another way. Right now, if anything fails also the m3u file is not written and most of the time it is only for very few (one) unavailable audio file, or failed metadata retrieval. I did not read much of the code... but is the metadata queried retrieved from third party? Or is it from the main site using the playlist as a query basis? If it is like the second case, the m3u file could get saved right away even before starting the actual download, then the download can proceed as usual, simple and not changes to the code that actual works well.

[justin025]

All of the applications requests are received from spotify themselves, so no external calls. It would be difficult to save the m3u immedietly after parsing because the current workflow is as follows...

Parse item (determine if its a track/episode/audiobook/etc) Get item metadata Create download path based on metadata (format {album_name} {artist} etc) Download file to download path Embed metadata Fetch Lyrics Add to M3U file Repeat for next item

You can check downloader.py for more information.

I could move the M3U step higher in the queue so that it is created before the download, let me know your thoughts.

[0rkaM]

TLDR: I really don't want to create too much work for you, and for sure I don't want to introduce new problems by making changes in a workflow that is working.

But I do want to have the .m3u files (actually .m3u8) written down even if there are errors, especially if they are not critical (of course in my opinion as far).

LONG: ... and maybe I should explain why, or at least how I use your app:

About my playlist creation process, sometimes I find ideas around from other playlist, or songs, but most of the time I work and refine my own playlist from my own searches and only after the playlist is complete, I test it by getting onto another device that does not support the official app, but it is capable of better resolution and sonic reproduction.

Therefore, after a playlist is "ready", I download it using the source 'Share URL' feature, so having the "saving of the m3u file" failed at the very last, after each file were downloaded almost perfectly, it is frustrating and requires additional manual steps to remake that list work.

But I'm assuming, if I understand correctly from your description of the process, that it is instead designed to accommodate the creation of the playlist on the fly, even if done appending one song at the time while adding them to the download queue, and it also allows, for a way that accommodate my way of using it: for full queue at once and download of all the songs in a playlist, if it is given as a search argument.

I guess that the creation of the .m3u8 file could be between the 'Create download path...' and the 'Download file to download path' steps.

Let me know, if you consider that a proper solution.

Meanwhile I am going to check the mentioned downloader.py and testing v1.0.0pre for https://github.com/justin025/onthespot/issues/31

[justin025]

Can you please explain the difference between m3u and m3u8 files, I had another user complaining that the app was making m3u8 instead of m3u and I do not know the difference. Perhaps I can add a box to select your preferred format.

That sounds good I will move the m3u creation right before download and let you know when I have added it to releases.

[0rkaM]

.m3u8 is simply a UTF-8 version of the M3U format [source].

I don't know any technical, or format difference between M3U and M3U8 files except for the character encoding used. You can use UTF-8 on regular M3U file also, like most today do, but if you want to be proper, then they are better known for using different standards. M3U8 explicitly uses UTF-8

M3U8 files are the basis for the HTTP Live Streaming (HLS) format originally developed by Apple to stream video and radio to iOS devices, and which is now a popular format for adaptive streaming in general.

But they are now widely used, because with the UTF-8 encoding more international characters can be used [source]:

'UTF-8 is capable of encoding all 1,112,064[2] valid Unicode code points using a variable-width encoding of one to four one-byte (8-bit) code units. Code points with lower numerical values, which tend to occur more frequently, are encoded using fewer bytes. It was designed for backward compatibility with ASCII'

P.S.: your app is fine; it is saving .m3u8 files, at least as I tested on Win10. I don't see why someone would want the old encoding and if so, why? And which one specifically? (maybe they are using something that does not handle UTF-8 well)

P.P.S: sometimes you can find .m3up, just a residual of older rare denomination, but they are the same of .m3u8