The VideoLAN Forums

One very unfortunate interaction between the regular streaming controls and the converting action is taking place if playlist loop/loop one is toggled on, which leads to the conversion of a network stream restarting indefinitely. I also noticed that with short videos, the videos are never properly downloaded and converted. I tested this with a 15 seconds long video and the resulting mp4 file was either only 2kb big and thus unplayable, or artifacts would be introduced or the aspect ratio randomly changed.

This is intended. It's quite normal to run an infinite stream with a loop.

Is it inteded that a download/conversion of a file is infintely repeated? Because I can't think of any use-case where you'd want that. VLC is just infinitely asking to overwrite the file it just created, especially annoying if the media is short and the download completes almost instantly. It basically soft-locks VLC in an indefinite "File already exists. Override?" loop.

From the computer's standpoint, there's no difference between a download and a stream.

Yes, but for the user there very much is. If I want to download/convert a video, I don't want the download action to loop, for obvious reasons.

Then don't set the loop. VLC is not going to second guess what you want.

The loop was still toggled from a previous instance. I only noticed after VLC kept asking me if I wanted to overwrite the file it just created. In fact, I first thought it was a bug.

Again, I don't see any reason why anyone would want to loop a download/conversion. So I suggest to patch VLC to ignore the loop toggle if a download/conversion is queued, as those actions generally aren't meant to be looped. Or don't add download-/ conversion actions to the playlist queue in the first place

@UmBottesWillen In VLC, the playlist component used for playback is the same as the playlist used for transcoding.

This design is problematic because there are a lot of differences between a playlist and a transcode queue, for example (not exhaustive):
- the items already encoded must not be moved
- double-clicking on an item should probably not stop the current encoding
- the transcoding must not loop over the list (nor shuffle)
- specific information might be shown specifically for transcoding items (encoding time, %progress, preset name, etc.)
- transcoding could be multi-threaded
- …

What Rémi says is that given that playback and transcoding are handled the same way, then it is "expected" to get the same behavior (in particular loop/shuffle) as playback.

But from a feature/UX point of view, this is a failure. IMO transcoding would require a totally separate components with a different behavior. But that's currently not the case in VLC, so as a workaround for now, I may only suggest to disable the loop :/