The VideoLAN Forums

This bug has been in this program basically since I've begun using it and is frankly gotten worse and is at the point of driving me to change programs.

It is a small one but incredibly irritating as it is happening more and more often. What happens is between every 2 to 10 videos played at the end of the file the vlc window expands to a massive size. Generally something like 2,000 pixels square. It will stay this size until you manually resize it. This is usually an annoying process as the window is so big two of it's sides are off the edges of the screen so you have to shrink it a bit, then move the window to show more of it and continue resizing.

This bug has been in the program for years now. It is not specific to one pc as in that time I've used it on several machines every one of which had the bug display itself. It may seem trivial but keeping it's size is a basic function which currently is very unreliable and having to resize the window a couple of times a day every day is getting beyond a joke. I did report it over a year ago but it's actually happening much more now.

You would need to be a bit more specific. Screenshots?

Yes, it's true. I think this trouble is linked to maximize button on upper right corner of VLC.
Try this:
-Open a video file
-Maximize
-Close VLC
and now:
-Open a video file from explorer context menu
-Resize VLC window
-Stop video file
Result: VLC window is out of screen.

My personal advice: do not use the maximize button, use fullscreen mode only.

Yes, this is a bug of Qt.

Okay here is a screenshot of the bug in action. This is what happens every few plays and occurs whether you let the file reach the end of stop it just before. It is not a Qt bug as I have very few videos using quicktime. I tend to play video's at their original resolution as I prefer the sharper image. So just prior to the snapshot below the video window was 512x384 and this happened when the video ended.

Qt is Qt4, not QuickTime.

Ahh I see. I had to look up what that was as I have never heard of it.

Does this mean you are not able to do anything about this bug?

In principles, the problem must be fixable. But, I would say that it is economically unfixable to borrow insurance terminology.

In theory, someone could go and investigate within the Qt4 source code, fix the bug and make a patch for VLC. But that would probably take software engineering man-months. Somehow, I doubt that anybody would offer that to the project.

At the risk of sounding rude what sort of attitude is that? We are talking about a glitch that causes users to have to "Adjust" your program at least once a day. (well for me at least I don't know how often it is happening for others.) If you keep ignoring bugs that might take a bit of effort to fix what sort of program are you going to end up with?

Would a car dealer spend a day to fix your car for free? No.
Would a clinic cure fix your broken leg for free? No.
Why would a software engineer manifest spontaneously to fix your bug for free?

You should be grateful that you got the mostly working software for free as well as answers on this support forum.

Some FRAMES of some source files cause VLC to RESTART

I am hit by this same resizing bug and it's very annoying, ricktu was actually very moderate compared to the damage. But I think my case can help finding the bug.

I saved ~1h10 from HD TV in a 2.3GB m2ts file and I am trying to make, out of it, about 20 smaller m2ts files that will be played, as tracks, by a couple playlists (e.g. one playlist for the whole show, one for the music parts only, one for the interview parts only, etc).

I use SmartCutter 1.6.1 to cut track #1 (New START Point, New END Point, Record), I rename it immediately, then back in SC, I click "clear" and cut the next track, and so on. Then in VLC I create the playlist.

Now after creating the 7 first tracks, VLC plays them nicely, including almost seamless joins; excepted that when starting track #5, the join is not seamless at all: VLC suddenly displays its giant black screen with the VLC icon in the middle, for about 0.75s (this is actually very long when you suffer it), then starts track #5 in that giant resized screen, so I have to manually resize. During my creating the tracks, this happens systematically each time I start track #5, hence a dozen times an hour.

Whatever the way to reach a track (navigating forward or backwards the playlist in VLC, or dragging a track file from Windows Explorer onto VLC title bar), other tracks start immediately without resizing, but track #5 triggers the bug.

I opened the playlist in Notepad++, track #5 is no different there. I renamed the track files to make them simple and similar, recreated the playlist, no avail.

I recreated track #5 in SmartCutter, same START (frame 1 of the wanted final track) and END Points, no avail.

So I think that in the raw m2ts file I start from, there is something, in the frame on which I start track #5 I presume, that triggers this bug; this must cause VLC to restart instead of simply, as it does on the 6 other tracks, switch to the next track in the playlist.

For the resizing part, Google "One file in VLC Playlist resizes the player" > How to prevent VLC from automatically resizing its window according to viewed content resolution? gave me the solution: in "VLC > Tools > Preferences > Show settings: All > Interface > Main interfaces > Qt", CLEAR (uncheck) the "Resize interface to the native video size" checkbox.

Once this remedy applied (and VLC duly restarted), when track #5 starts, it doesn't resize VLC anymore; but it still shows its black screen with the VLC icon for ~0.75s, which disturbs the video experience and destroys its quality; this remains pretty annoying.

So apparently the problem is actually NOT with resizing but with RESTARTING VLC.

I tested re-cutting track #5:

• starting on frame 2 (of the wanted final track #5), fail.
• Starting on frame -5 of track #4 (I mean the 5th frame backwards starting from end track #4), OK.
• Starting on frame +5 of wanted track #5, the black screen and icon still shown, but just a blink, so I tried:
• Starting on frame +6 of wanted track #5, OK. And at that time the music hasn't started yet, so in this case I am solved. But the general problem remains.

Hope this detailed report helps debugging...

Versailles, Wed 21 Nov 2012 23:46:00 +0100