Seems to be fixed in VLC 3.0.9.2-1 (Ubuntu 20.04); at least I haven’t been able to reproduce it anymore.

Same ”double free or corruption (!prev)” reproducible here too (VLC 3.0.9.2-1, Ubuntu 20.04), even more easily: the position doesn’t matter, and the first attempt to screenshot is already enough to trigger the issue.

I came across this when trying to screenshot a Superman cartoon I downloaded from Internet Archive [1].

* [1] https://archive.org/download/dom-6746superman-episode7-theundergroundworld512kb/dom-6746superman-episode7-theundergroundworld512kb.mp4

I’m seeing memory-related crashes when playing videos sliced (with ffmpeg -c copy) from mp4 streams (downloaded with youtube-dl). I’m attaching a sample clip which, granted, is pretty useless for a video, but which produces these crashes with 100% certainty for me; I just edited it down to a reasonable size and non-infringing content.

The errors reported just before core is dumped are (mostly) ”double free or corruption (fasttop)” or (less often) ”malloc_consolidate(): invalid chunk size”.

To be clear, my expectation here is not for the problematic clips to have useful content, or even to play back; just that vlc didn’t crash. (Totem for instance does not seem to crash with the same files.)

I’ll attach logs for both the double free and malloc_consolidate cases (which I’m producing by running LC_ALL=C vlc -vvv out.mp4 in a loop).

Steps to reproduce:

1. Load a playlist of N files in VLC
2. Set playback to Random
3. Play or jump (with ”Next” button) the playlist forward for N files and observe the playing order
4. GOTO step 3

What happens:
The order in which the files are played in step 3 always repeats itself.

What I expect to happen:
For the files to be played back in a truly random order, without any perpetually repeating pattern.

Further info:
The playing order seems to get shuffled only at the start, so the playlist isn’t played in order, but the once-shuffled order is repeated over and over. To reshuffle the playlist, VLC has to be restarted, but still then it just plays the newly-shuffled playlist over and over.

To be fair, in practice instead of true randomness I suspect most people prefer something from the way the ”Random” now works: that each file on the playlist is played once and once only in every N plays. AFAICT it is not mutually exclusive with reshuffling the playlist between those N plays; just make sure that the two transitional files (last file of shuffled-playlist-1 vs. first file of shuffled-playlist-2) aren’t the same.

I for one though would still prefer even true random over what it currently is.

Of the half a dozen or so randomness-related bugs in VLC’s tracker I was able to find, Ticket #5730 (”New Feature Request: Shuffle & Random for Playlists”) [1] came closest to what I’m reporting here. In fact, it’s a superset of this one and I’d prefer to have it fixed over just mine.

*[1] http://trac.videolan.org/vlc/ticket/5730#trac-ticket-title

Note to others here suffering from this with Radeon HDMI only as I am: as per @David’s comments, I’ve just filed Bug #927323 about this.

Tylsyys on katsojan silmässä, minusta tämä oli oikein mielenkiintoinen. Onko tosiaan niin ettei VLC:tä koneellesi saa? Se kuulostaa minusta vähän hassulta, sillä yleensä vapaiden ohjelmien saatavuutta ei juurikaan rajoiteta, edes laitekannan perusteella. Eri asia on sitten tietysti se, onko vanhan koneen rauta liian hidasta pyörittämään jotain ohjelmaa.