convert more than one video at a time

[abe-101]

Issues or necessity of a feature It would convenient if the project could convert more than one video at a time

[abe-101]

What id we coud have more video ID in the episode.json file and the script would convert all of them

[abe-101]

it would be best if the script kept the browser session for all the video's (avoiding having the script to log in for each video

[matevskial]

My idea is to add another field besides id in episode.json, ids that would be an array of strings:

{ 
    "id": "uZZoDaVdCAE",
    "ids": [ "IG_VDj8Eh_g", "cF3OWCYLLVQ"]
}

Additional note: If both fields id and ids are present, then all videos ids from both fields would be posted to anchorfm, with the field id being the first video id to be uploaded.

Episode.json will have valid content if either both fields id and ids are contained, or just one of them.

Also, another thing to take care of is the error handling: when do we want the github action to fail, if no video got posted to anchorfm, if only some videos get posted to anchorfm or skip error handling entirely?

[abe-101]

My idea is to add another field besides id in episode.json, ids that would be an array of strings:

{ 
    "id": "uZZoDaVdCAE",
    "ids": [ "IG_VDj8Eh_g", "cF3OWCYLLVQ"]
}

I like this approach because it's backward compatible

[abe-101]

Also, another thing to take care of is the error handling: when do we want the github action to fail, if no video got posted to anchorfm, if only some videos get posted to anchorfm or skip error handling entirely?

In my opinion, the process should proceed even if one fails but it should report at the end which ids succeeded and which failed

[nicpuppa]

My idea is to add another field besides id in episode.json, ids that would be an array of strings:

{ 
    "id": "uZZoDaVdCAE",
    "ids": [ "IG_VDj8Eh_g", "cF3OWCYLLVQ"]
}

What happening if we remove the id field instead ? Would this simply result in updating the old episode.json files ?

In my opinion we could think of removing the id field, so if you want to upload only one video, you would enter an array of only one id otherwise you would enter n ids.

[matevskial]

What happening if we remove the id field instead ? Would this simply result in updating the old episode.json files ?

In my opinion we could think of removing the id field, so if you want to upload only one video, you would enter an array of only one id otherwise you would enter n ids.

The idea to keep both id and ids is simply for backward compatibility and convenience

But if we are to remove id, probably we should first deprecate that field, give a warning in the logs, and after several releases remove the field completely.

[matevskial]

Also, another thing to take care of is the error handling: when do we want the github action to fail, if no video got posted to anchorfm, if only some videos get posted to anchorfm or skip error handling entirely?

In my opinion, the process should proceed even if one fails but it should report at the end which ids succeeded and which failed

When GitHub action fails, I receive an email from GitHub that the action failed, and this is very useful, because in most cases from my experience, the action fails only when Anchor.fm changes something in their web page and we need to update the code accordingly.

In that case, it would be a waste of time to process all videos because every video will fail.

On the other hand, what if we want to keep order of the episodes, do we want to care about the order of the videos they are specified in the field ids? Let's say we have

{ 
    "ids": [ "IG_VDj8Eh_g", "cF3OWCYLLVQ", "2pfLE5YJ1Fo"]
}

And let's say the second video cF3OWCYLLVQ fails to be posted for some reason. If we proceed without stopping, then the next video 2pfLE5YJ1Fo might be posted successfully.

In that situation only two videos(the first and the third) would be posted, but not the second. We would post the second video if we run another GitHub action and in the end the videos would be posted out-of-order, that is, if we care about order at all.

[nicpuppa]

But if we are to remove id, probably we should first deprecate that field, give a warning in the logs, and after several releases remove the field completely.

I think this should be the right solution, deprecate the field id, and then remove

[nicpuppa]

When GitHub action fails, I receive an email from GitHub that the action failed, and this is very useful, because in most cases from my experience, the action fails only when Anchor.fm changes something in their web page and we need to update the code accordingly.

In that case, it would be a waste of time to process all videos because every video will fail.

On the other hand, what if we want to keep order of the episodes, do we want to care about the order of the videos they are specified in the field ids? Let's say we have

{ 
    "ids": [ "IG_VDj8Eh_g", "cF3OWCYLLVQ", "2pfLE5YJ1Fo"]
}

And let's say the second video cF3OWCYLLVQ fails to be posted for some reason. If we proceed without stopping, then the next video 2pfLE5YJ1Fo might be posted successfully.

In that situation only two videos(the first and the third) would be posted, but not the second. We would post the second video if we run another GitHub action and in the end the videos would be posted out-of-order, that is, if we care about order at all.

The order of element inside the field idsis important, so if one upload fail we should stop the process and not try to post the remaining video

[matevskial]

I think this should be the right solution, deprecate the field id, and then remove

I agree with this, in order to not make a mistake of keeping things for the sake of backward compatibility and bloat the project.

The order of element inside the field idsis important, so if one upload fail we should stop the process and not try to post the remaining video

I also agree with this for a couple of reasons:

• If the reason for failing is because of Anchor.fm web page, then all videos will fail to post.
• If the order of the upload matters

Just keep a note that if the environment variable SET_PUBLISH_DATE is set to true then the order of the videos would be set by the publish date in Anchor.fm.

[abe-101]

Keeping the order of the videos is a very valid point

I would just like to bring to your attention hat the process could fail for other reasons

One that comes to mind is if a youtube video doesn't have a description Anchor fm won't allow you to save an episode without a description So the process fails out

[matevskial]

I see, so here is an idea:

What about a new environment variable to specify whether to fail fast or proceed when one upload fails? For example environment variables like STOP_EARLY_ON_FAIL or IGNORE_FAILED_UPLOADS or something like that?

Of course the default setting would favor stopping the process if at least one upload fails.

[abe-101]

@matevskial Do you have time to work on this?

[matevskial]

These days no, busy with stuff :)

[TheJoin95]

Closing this, feel free to reopen it if you're going to find some time to implement it

[Wabri]

Why not just let open and mark with help wanted or good first issue?

[TheJoin95]

Not sure. It's been there since 2022, I believe it's not relevant anymore but I don't have a strong opinion.

Maybe it's better to open a new one with some requirements in it