Qt UI becomes unresponsive on stream of errors

added Component::Core: Input Difficulty::hard labels

changed milestone to %Bugs paradize

This is not really new, and it is hard to avoid. You just get an infinite loop of trying to open a file that does not exist.

In fact, you can still close the player. It takes a while because Qt4 is slow at continuously updating the error dialog.

@courmish I don't think this is hard to avoid, but I didn't look at the code (maybe could you link me it?)

I think the playlist in memory is mapped as a linked list (maybe with back and foward pointers).

So when a file isn't available anymore just delete the node and check the next one. When the list is empty just stop.

This should be a theoretically way to implement this, but I say I didn't look at the code, maybe your implementation is so different that a change will be impossible to do, but if you link me the c source of this module I'll be so glad to help ;)

thanks

There is no generic way to check that an input item does not exist anymore. It might work if the item is a local file, but even then it is highly questionable that absent items should be deleted. The file could be created/recreated later. Besides, it would be quite hard to propagate the error back to the playlist model.

In my opinion, the current behaviour of using whole CPU is correct: the user requests an infinite loop, (s)he gets it. The responsiveness problem is all on Qt4 UI side.

added Component::Interface: Qt + 1 deleted label and removed Component::Core: Input label

You pointed out a really good question and I think you can be right.

Anyway just two hints, if you want to fix the problem you can close the file, and try to open it again, if the file has been deleted the open will return NULL.

The second is that there is a memory leak, when VLC goes into the infinite loop the memory consumption slowly increases until all the ram is taken (and this slow increase is really annoying because the kernel takes something like 5 hours to kill it and the system is unusable because the cpu is 100%)

So I think you may look at the leak and IMAO the problem can be fixed in two ways:

put a delay (1 second maybe) when a file isn't found, this will let the user close vlc without invoking a kill -9 from bash
when a file isn't found anymore ask for the user with "I cannot find the file, would you like to remove it from the playlist?" (this is the behavior of programs like vmp)

Patch welcome.

changed title from Vlc becomes unresponsive to Vlc becomes unresponsive when looping over an absent item

3 years. Can you at least add an option to autodelete missing items from playlist? It's really annoying when reorganizing your audio collection.

5 years! :-)

This doesn't occur often but it is still annoying and it's still a bug.

There are two separate issues:

The VLC playlist can go into an infinite. As I already wrote in comment:5, this is, in my opinion, a user error, not a VLC bug.
The Qt GUI becomes very unresponsive and almost unusable when the playlist generate errors at a high frequently. This is a VLC Qt GUI bug; there are no such issues with other interfaces.

the user requests an infinite loop, (s)he gets it.

The user does not request the infinite loop that makes their player unusable. It is trivial to reach this state not only by trying to play a dead file but also by pasting an incorrect web URL or similar.

My suggestion would be that if VLC tries to play the same file twice in a row (with no user interaction inbetween) without success, it stops auto-advancing the playlist. This is pretty much how other media players do it as well. If a file failed to be played twice in a row, it's unlikely that it will succeed a millisecond later. Don't proceed to the next (or rather, same) playlist entry anymore in that case.

I experienced this today after cleaning up my music library, reordering/renaming/re-tagging, etc. A lot of file names and paths changed.

I opened up a playlist I created before the reordering and none of the files could be found. Loop was on, so VLC kept throwing errors and eventually froze, as is described above.

the user requests an infinite loop, (s)he gets it.

... except I didn't. I opened a playlist, got some errors (great), and experienced a program crash (not great). So VLC can not handle the case where files move. I was never given the opportunity to repair my playlist. I haven't tried it, but I feel like this would be much more obnoxious on a mobile (Android) platform.

Windows Media Player handles this by marking missing files in the playback list and skips them. If I manually attempt to play that file again, it will attempt a read, but will throw another error again if it doesn't exist. No infinite loop. Throws errors that I can resolve.

If a "valid" tag can't be added to the play queue list, maybe limiting the rate at which the player moves to the next file after an error would help? If there are lots of errors in succession, VLC would increment a delay before attempting to load the next file.

- Load file
- Fail load
- wait(0)    
- Load file  <--
- Fail load     |
- wait(+ N)  ---

Replying to [comment:13 thumbcore]:

the user requests an infinite loop, (s)he gets it.

... except I didn't. I opened a playlist, got some errors (great), and experienced a program crash (not great). So VLC can not handle the case where files move. I was never given the opportunity to repair my playlist. I haven't tried it, but I feel like this would be much more obnoxious on a mobile (Android) platform.

So what's the difference between what you did, and a user actually asking for an infinite loop? And yes, this is a real use case, notably in unattended cases.

changed title from Vlc becomes unresponsive when looping over an absent item to Qt UI becomes unresponsive on stream of errors

Also #2284 (closed)

Regardless of whether an intinifte loop is initiated by user error, it is quite possible to warn the user that what he has requested is likely not intentional.

An infinite loop is indeed a valid use case, and thus should not trigger any kind of warning or error. Unless it means looping though items wich cannot be played, or looping though items which are each shorter than say 3 seconds. In those two examples, it is fair to assume the user does not intent infinite looping, as it will become hard to interact with VLC. If such occurances can be detected ahead of initationg playback, it should throw a warning and ask the user if this is truly his intent.

In practice, there might be need for another solution, as detecting these cases would mean parsing ahead of time which items can be played, and what the lenght of the playable items is (even the the playback speed setting becomes relevant, because playback at half speed might mean there is no issue to warn the user about, if short items are played slowly, the user will have plenty of time to interact with the user interface).

Instead of throwing a warning, another more elegant solution would be to revise the way the userinterface is updated, so even if short items are played in an infite loop, there is no difficulty interacting with the user interface. This solution would negate the need for parsing the items ahead of time, and negate the need for a warning dialog. Whether it is possible however is a much more technical discussion.

The above is quite obvious. The more interesting case in my eyes, is a combination of normal playable items, and a few unplayable items, in a looped playlist. There is a use case for retrying an item, however when playing from file, and the fle has not been altered since the last attempt, thowing an error again just gets annoying to the user and provides little to no new information. If it is possible, I would suggest to come up with a check whether or not an item has been attempted and failed playback before, and whether or not this item is a static file which has not been updated since the last attempt. If so, don't attempt again, and thow a warning instead of an error (warning: skipped item because it has been attempted before, and failed playback). Otherwise do attempt playback.

There is a difference between these cases. This ticket #5901 (closed) describes a looping though unplaiable items or very short items, causing the user interface to lock up. The issue I just described however, does not cause the user interface to lock up, as there are also plenty of normal lenght playable items populating the playlist, giving the user plenty of oppertunity to interact with VLC. Never the less, gettign errors for each re-attempt on a file which has already thrown an error before can also be regarded undesirable, and might also be fixed. The issues are closely related, also from a technical stance, but are not identical. I described the issue which does not tigger a lockup of the user interface in #18582 (closed). It has been marked a duplicate of this ticket (understandably so), but I would like to emphasise that difference, as it might get overlooked if we solely focus on the case of the user interface locking up.

There will always be ways for the UI to get a lot of errors. After the most obvious case of repeating a nonexistent file is addressed, there will be the problem of repeating a file that cannot be parsed, or a resource with an invalid URI, or an invalid sout chain, and so on.

IMO, the GUI really shall not become unresponsive, regardless of how many errors occur and how short played items are.

How about just implementing some kind of backoff for playing failed items?

As some previous commenters said, if the file fails to play x times in a row retrying instantly probably won't help and adding a few 100 ms won't be exactly noticable either, but would probably help keep the level of error messages to a sane amount.

Qt UI becomes unresponsive on stream of errors

Child items 0

Activity